Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.bugs.4bsd
Subject: Re: Running stdin/out through a pipe to a child process
Message-ID: <5143@mimsy.UUCP>
Date: Thu, 22-Jan-87 03:52:58 EST
Article-I.D.: mimsy.5143
Posted: Thu Jan 22 03:52:58 1987
Date-Received: Thu, 22-Jan-87 06:37:46 EST
References: <136@cogent.UUCP> <3112@rsch.WISC.EDU> <423@bobkat.UUCP> <145@quacky.mips.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 27
Xref: mnetor comp.unix.questions:791 comp.unix.wizards:682 comp.bugs.4bsd:144

In article <145@quacky.mips.UUCP> dce@mips.UUCP (David Elliott) writes:
>2. Two pipes are opened and written to. Next, both pipes are closed. Finally,
>each child process is waited for. All goes as expected, except that I
>find it odd that the second child is found by wait() first.

Child collection order is not guaranteed anywhere, so do not count
on it working either way.  Yet this is a clue, to those who have keen
sight:

>3. Two pipes are opened and written two [sic]. Afterwards, each pipe
>is closed and the child process waited for (that is, pipe 1 is closed
>and child 1 is waited for and then pipe 2 is closed and child 2 is
>waited for). In this case, the first wait() blocks, and the first
>child never terminates except when the parent does.

An instant analysis:

Child 2 is still able to write to child 1, having in its posession
a descriptor for the write end of the pipe to child 1.  Child 1
will not exit until child 2 exits or otherwise discards this
descriptor.  This should be easy to confirm, by code inspection,
or by adding `gratuitous' close() calls.  This is yet another
example of why it is necessary to use care as to who has descriptors
to which ends of what pipes.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu