Date: Sun, 16 Jun 1996 11:27:21 +1000 From: Bruce Evans <bde@zeta.org.au> To: cimaxp1!jb@werple.net.au, zeta.org.au!bde@melb.werple.net.au Cc: hackers@FreeBSD.org, jb@cimlogic.com.au Subject: Re: Nonblocking writes to pipes hang Message-ID: <199606160127.LAA31411@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> 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
It should be easy for the author :-).
>writes < 8192? I assume the problem exists in both 2.1R and 2.2-current.
No, it is only in -current. The code for nameless pipes was completely
rewritten for -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
I had trouble duplicating the problem with my benchmark program. Here's
a minimal program to demonstrate the problem:
---
main()
{
char buf[1];
int fd[2];
pipe(fd);
switch(fork())
{
case -1:
perror("fork");
exit(1);
case 0:
#ifdef CLOSE
close(fd[1]);
#endif
read(fd[0], buf, sizeof buf);
printf("reader exiting\n");
exit(0);
default:
sleep(1);
printf("writer exiting\n");
exit(0);
}
}
---
This works right if CLOSE is defined. Otherwise the reader hangs. The
behaviour under Linux is identical. Apparently I was wrong about where
the critical extra vnode reference comes from.
>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.
Pipes usually work in such setups, so I guess everything is being careful
about closing unused fd's.
>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".
Vnode reference counting problems aren't easy to fix without introducing
other problems.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606160127.LAA31411>