Xref: utzoo comp.bugs.4bsd:1283 comp.unix.wizards:16508
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!execu!sequoia!rpp386!jfh
From: jfh@rpp386.Dallas.TX.US (John F. Haugh II)
Newsgroups: comp.bugs.4bsd,comp.unix.wizards
Subject: Re: Shared file descriptors
Summary: flawed assumption.
Message-ID: <16601@rpp386.Dallas.TX.US>
Date: 31 May 89 01:29:55 GMT
References: <1770@taux01.UUCP>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: River Parishes Programming, Plano TX
Lines: 39

In article <1770@taux01.UUCP> gil%taux01@nsc.COM (Gil Shwed) writes:
>	main() {
>		char buf[8192];
>		int n;
>
>		fork();
>		while((n = read(0, buf, 8192)) > 0)
>			write(1, buf, n);
>		exit(0);
>	}
>	Then, run:
>
>		a.out < /vmunix > out
>
>	Now, run:
>		cmp /vmunix out
>
>	They should be the same, but...

No, they shouldn't.

You are assuming the read-write pair is atomic, which it isn't.  It
would be quite possible for either process to step in between a
read and write and copy another block.  A possible scenario is

proc 1:READ()  ... wait ...  WRITE()
proc 2:       READ() WRITE()

In this situation, input block 0 would be output block 1, and so
on.

I'll leave the more pathological cases to your imagination.  This
does not appear to contradict the claim that there is a bug, but
it does question your methods ...
-- 
John F. Haugh II                        +-Button of the Week Club:-------------
VoiceNet: (512) 832-8832   Data: -8835  | "AIX is a three letter word,
InterNet: jfh@rpp386.Cactus.Org         |  and it's BLUE."
UucpNet : <backbone>!bigtex!rpp386!jfh  +--------------------------------------