On Tue, 5 Sep 2000, Peter van Dijk wrote:

> On Tue, Sep 05, 2000 at 07:50:56PM +0400, Andrey A. Chernov wrote:
> > Consider this comment comes from screen(1):
> > 
> > /*
> >  * Define this if your system exits select() immediatly if a pipe is
> >  * opened read-only and no writer has opened it.
> >  */
> > #define BROKEN_PIPE 1
> > 
> > We have broken(?) pipe, according to this statement. At least, we have
> > select return code -1 with wrong errno == 0.
> qmail calls this 'named pipe bug 1'. The workaround (which screen
> probably uses too) is to let the process doing the select() also have
> one fd opened for writing on the pipe. With that write-open, select()
> will only return if there is actual data waiting inside the pipe.
> I have filed a PR (19871) for this I think about 2 months ago, somebody
> submitted a patch but I never gotten around to testing it.
> I surely do think this behaviour is broken.

This behaviour is sort of intentional.  Reads on a named pipe with no
writers are specified by POSIX.1 to return immediately.  4.4BSD does
extra work to break this in some cases.  select() on a read descriptor
open on such a pipe just follows read().  I think it started giving
the behaviour that you don't want when I fixed read().

Linux gives the behaviour that you want by not following read() in
select() (more (precisely, in poll()).  It puts POLLHUP in the events
polled for read descriptors in select() and actually implements POLLHUP
for named pipes.  The special handling for select() then falls out of
the special handling for POLLHUP (polling on POLLHUP doesn't succeed
until there has been a writer).  FreeBSD doesn't do either of these
things.  It is also missing support for POLLHUP on ttys and sockets.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to