From owner-freebsd-hackers Sat Jun 15 17:17:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA25389 for hackers-outgoing; Sat, 15 Jun 1996 17:17:45 -0700 (PDT) Received: from melb.werple.net.au (melb.werple.net.au [203.9.190.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA25384 for ; Sat, 15 Jun 1996 17:17:43 -0700 (PDT) Received: from cimaxp1.UUCP (uucp@localhost) by melb.werple.net.au (8.7.5/8.7.3/2) with UUCP id JAA28030 for hackers@FreeBSD.org; Sun, 16 Jun 1996 09:17:02 +1000 (EST) Message-Id: <199606152317.JAA28030@melb.werple.net.au> Received: by cimaxp1.cimlogic.com.au; (5.65/1.1.8.2/10Sep95-0953AM) id AA10198; Sun, 16 Jun 1996 09:16:55 +1000 From: John Birrell Subject: Re: Nonblocking writes to pipes hang To: zeta.org.au!bde@melb.werple.net.au (Bruce Evans) Date: Sun, 16 Jun 1996 09:16:54 +1000 (EST) Cc: hackers@FreeBSD.org, jb@cimlogic.com.au In-Reply-To: <199606151304.XAA12653@godzilla.zeta.org.au> from "Bruce Evans" at Jun 15, 96 11:04:02 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk [ Bruce, thanks for taking the trouble to give a detailed reply. 8-). ] > Writes of >= 8192 bytes are just broken. pipe_direct_write() is > called in this case and it never checks the PIPE_NBIO flag. Is this easy to fix, or should we code to ensure we only do non-blocking writes < 8192? I assume the problem exists in both 2.1R and 2.2-current. > My pipe throughput test program shows another interesting pipe bug. > When WORK_AROUND_FREEBSD_BUGS is not defined, the reader sometimes hangs > waiting for EOF even though the writer has closed the pipe (or has > exited). Ugh. We rely on this _working_. The most common case where we use pipes is to re-direct output from one program to another. Our build process, for instance, execs cc, ar, ld etc with stdout and stderr piped back to the build program (which we use instead of make) so that we can save error and warning messages in the build version history. The only way that our build program knows when there is nothing more to read from the pipe when it is closed by the writer. > This is caused by last-close semantics being broken as > designed. The fileops close function only gets called when both the > reader and the writer have closed the pipe. Thus if the reader is > waiting for input and the writer dies, the pipe code doesn't get > notified and the reader continues waiting for input that can never > arrive. For named pipes, input can arrive, but reads still block for > too long. POSIX.1 requires that reads unblock when the pipe is closed > by all processes that had it open for writing. FreeBSD's bidirectional > pipes seem to fix the problem for the wrong reason - it is impossible > to close a read/write descriptor while you're reading from it, so it > is impossible for all writers to close a pipe that you're reading from. I don't know how we can work around this problem. Are there any issues that would prevent this problem being fixed? To us it is a "job-stopper". > > Bruce Regards, -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au 119 Cecil Street Ph +61 3 9690 6900 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137