Re: kern/55983: shortcomings in poll(2)

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

The following reply was made to PR kern/55983; it has been noted by GNATS.

From: Valery Ushakov <uwe%stderr.spb.ru@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/55983: shortcomings in poll(2)
Date: Tue, 9 Feb 2021 07:11:54 +0300

 On Tue, Feb 09, 2021 at 01:15:00 +0000, dholland%NetBSD.org@localhost wrote:
 
 > (1) Is the relationship between POLLIN/POLLOUT/POLLPRI and
 > POLLRDNORM/POLLWRNORM/POLLRDBAND the same in System V (and Linux) as
 > in NetBSD? In NetBSD these are synonyms, modulo POLLIN and POLLPRI
 > actually being distinct flags and thus being mishandled in a few
 > corner cases. If STREAMS causes System V to have more cases (which is
 > possibly consistent with the old wording of the man page, and hinted
 > at but not documented by the caveat at the end which I removed) they
 > should be documented as such.
 
 The paper copy of SunOS 5.1 STREAMS Programmer's Guide that I have
 around says on page 6-2, in summary:
 
 POLLIN -        a message other than an M_PCPROTO
                 (uwe: i.e. same as POLLRDNORM|POLLRDBAND)
 
 POLLRDNORM -    a normal (non-priority) message
 
 POLRDBAND -     a priority message (band > 0)
 
 POLLPRI -       a high priority message (M_PCPROTO)
 
 POLLOUT -       the normal priority band is writable
 
 POLLWRNORM -    the same as POLLOUT
 
 POLLWRBAND -    a priority band greater than 0 of a queue downstream
                 exists and is writable
 
 
 > (2) Is the behavior that sockets generate POLLRDNORM on hangup (like
 > with select) universal or NetBSD-specific? (Or somewhere in between?)
 > Either way it should be documented, because in the former case it's
 > somewhat unexpected and in the latter it's an important portability
 > consideration.
 
 Here's a survey:
 
   http://www.greenend.org.uk/rjk/tech/poll.html
 
 
 > (3) Is ppoll different from pollts? The man page describes it as a
 > wrapper, but the arguments are the same and I thought they were the
 > equivalent.
 
 It's a literal wrapper b/c linux calls it ppoll, while we called it
 pollts.  See the thread started here:
 
   https://mail-index.netbsd.org/tech-userlevel/2020/05/25/msg012466.html
 
 kre@ says about ppoll that:
 
 | It has been (twice now) proposed to posix to be added (both still
 | pending, linked as duplicate reports) and my guess is is quite
 | likely to be added in the next version.
 
   https://mail-index.netbsd.org/tech-userlevel/2020/05/25/msg012475.html
 
 
 > (4) The previous version of the man page went out of its way to note
 > that you can't get POLLHUP and POLLWRNORM back together, and I kept
 > that in the new version, but what about POLLWRBAND or other I/O flags?
 > ISTM that a hung-up file should not select for any kind of read or
 > write, or return anything else either.
 
 I guess that follows the STREAM docs.  In the POLLHUP description it
 says that "[POLLHUP] and POLLOUT are mutually exclusive".  (Note that
 on Linux failed connect(2) is reported as POLLERR|POLLHUP|POLLOUT last
 time I checked)
 
 
 > (5) We should document what you're supposed to do in response to
 > receiving POLLERR, since it's not obvious, nor is it obvious what is
 > safe to do at that point without blocking, but because none of this is
 > obvious I have no idea what to write.
 
 STREAMS docs says that POLLERR means that a fatal error occured in one
 of the drivers associated with the stream and further syscalls will
 fail.
 
 
 > (6) The "more useful" behavior described in COMPATIBILITY is...
 > NetBSD-specific? Shared with FreeBSD? Universal except for legacy SVR4
 > clones? This should be documented.
 
 I'm not sure what that passage is supposed to mean.  There's POLLNVAL.
 
 
 -uwe