From owner-freebsd-bugs@FreeBSD.ORG Fri Mar 24 22:00:42 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2486C16A400 for ; Fri, 24 Mar 2006 22:00:42 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCBBF43D45 for ; Fri, 24 Mar 2006 22:00:41 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k2OM0f7A020118 for ; Fri, 24 Mar 2006 22:00:41 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k2OM0f72020117; Fri, 24 Mar 2006 22:00:41 GMT (envelope-from gnats) Date: Fri, 24 Mar 2006 22:00:41 GMT Message-Id: <200603242200.k2OM0f72020117@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Oliver Fromme Cc: Subject: Re: kern/94772: FIFOs (named pipes) + select() == broken X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Oliver Fromme List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2006 22:00:42 -0000 The following reply was made to PR kern/94772; it has been noted by GNATS. From: Oliver Fromme 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