Date: Fri, 24 Mar 2006 22:00:41 GMT From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/94772: FIFOs (named pipes) + select() == broken Message-ID: <200603242200.k2OM0f72020117@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/94772; it has been noted by GNATS.
From: Oliver Fromme <olli@lurza.secnetix.de>
To: bde@zeta.org.au (Bruce Evans)
Cc: bug-followup@freebsd.org
Subject: Re: kern/94772: FIFOs (named pipes) + select() == broken
Date: Fri, 24 Mar 2006 22:53:45 +0100 (CET)
Bruce Evans wrote:
> Oliver Fromme wrote:
> > So you mean in the SBS_CANTSENDMORE case, POLLHUP should be
> > set without checking if the caller has requested POLLOUT in
> > the events mask? That sounds reasonable, because POLLOUT
> > certainly can't be returned in that case. It makes the
> > code more complex, though.
>
> Yes. POLLHUP Is also needed for making poll() return for poll()
> waiting for input only. I think it would make the code slightly
> less complex.
You're right. My patch made that part of the code slightly
less complex, indeed.
> I'm interested in what non-Linux non-FreeBSD systems do.
DEC UNIX 4.0D doesn't return POLLHUP at all, only POLLIN.
I can give the detailed output, but I think it's not very
interesting, given the fact that that system is about 7
or 8 years old. Unfortunately I don't know anybody with
access to a Tru64 machine, which would be more interesting.
Solaris 9 seems to behave exactly the same as Linux in the
test program, i.e. it passes all checks successfully.
Given the fact that Solaris went the Linux route (or vice
versa), that's a strong point that FreeBSD should do the
same.
NetBSD 3.0 is very interesting, so I give the detailed
output from the test program (which I modified to produce
regression test compliant output, see my other mail):
1..26
ok 1 Pipe state 4: expected 0; got 0
ok 2 Pipe state 5: expected POLLIN; got POLLIN
ok 3 Pipe state 6: expected POLLIN | POLLHUP; got POLLIN | POLLHUP
not ok 4 Pipe state 6a: expected POLLHUP; got POLLIN | POLLHUP
ok 5 Pipe state 4: expected 0; got 0
ok 6 Pipe state 5: expected POLLIN; got POLLIN
ok 7 Pipe state 6: expected POLLIN | POLLHUP; got POLLIN | POLLHUP
not ok 8 Pipe state 6a: expected POLLHUP; got POLLIN | POLLHUP
ok 9 FIFO state 0: expected 0; got 0
ok 10 FIFO state 1: expected 0; got 0
ok 11 FIFO state 2: expected POLLIN; got POLLIN
ok 12 FIFO state 2a: expected 0; got 0
not ok 13 FIFO state 3: expected POLLHUP; got POLLIN
ok 14 FIFO state 4: expected 0; got 0
ok 15 FIFO state 5: expected POLLIN; got POLLIN
not ok 16 FIFO state 6: expected POLLIN | POLLHUP; got POLLIN
not ok 17 FIFO state 6a: expected POLLHUP; got POLLIN
ok 18 FIFO state 0: expected 0; got 0
ok 19 FIFO state 1: expected 0; got 0
ok 20 FIFO state 2: expected POLLIN; got POLLIN
ok 21 FIFO state 2a: expected 0; got 0
not ok 22 FIFO state 3: expected POLLHUP; got POLLIN
ok 23 FIFO state 4: expected 0; got 0
ok 24 FIFO state 5: expected POLLIN; got POLLIN
not ok 25 FIFO state 6: expected POLLIN | POLLHUP; got POLLIN
not ok 26 FIFO state 6a: expected POLLHUP; got POLLIN
That means two things:
1. When POLLHUP is returned, POLLIN is also always
returned.
2. For FIFOs, POLLHUP is not used at all, but POLLIN
is used instead. This is the behaviour that Stevens
describes in APUE, by the way.
I guess portable programs cannot rely on the results from
poll() too much ... They probably just look if at least
one of POLLHUP and POLLIN is set, and then call read().
Otherwise they would break on one platform or another.
Here's a web page from someone who did similar tests on
a wide range of operating systems:
http://www.greenend.org.uk/rjk/2001/06/poll.html
His conclusions are a little bit different. *SIGH*
It's all the fault of fuzzy SUS/POSIX. :-(
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"A language that doesn't have everything is actually easier
to program in than some that do."
-- Dennis M. Ritchie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603242200.k2OM0f72020117>