From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <2edd17c34e530d3810c4150f4c907f32@vitanuova.com>
Date: Fri,  1 Sep 2006 11:57:38 +0100
From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] trying to understand how fork/pipe a filtering program
In-Reply-To: <6f2597316d0e00150a0c4bd2cc06bcee@plan9.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: ad9824d4-ead1-11e9-9d60-3106f5b1d025

> Maybe it's been too long a week, but I could have sworn that a Plan 9
> pipe was a pair of unidirectional channels (queues in Streams
> terminology), so closing one end would cause a zero-byte read at the
> other, independently in each direction.  pipe(3) seems to support
> this.

the problem is that neither end was actually being closed,
as both ends of the pipe were dup'd onto stdin/stdout of the
child process. (the underlying close only happens when all references
have gone).

there is an alternative, i realised last night - you can do a zero-length
write after doing the writeimage, which will cause the child to read EOF,
which is usually fine (unless the child re-reads EOF, expecting it to remain EOF,
which can be the case with some buffered IO libraries and one-char lookahead;
depends whether it implements ungetc(EOF) - bio has this issue, for example)