Re: kern/54435: reading TCP urgent data with MSG_OOB doesn't clear poll(2) status

[Michael van Elst <mlelstv%serpens.de@localhost>]

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

From: Michael van Elst <mlelstv%serpens.de@localhost>
To: Valery Ushakov <uwe%stderr.spb.ru@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: Re: kern/54435: reading TCP urgent data with MSG_OOB doesn't clear
 poll(2) status
Date: Mon, 5 Aug 2019 11:22:50 +0200

 On Mon, Aug 05, 2019 at 10:21:10AM +0300, Valery Ushakov wrote:
 
 > I asked for a reference (a book, an old mail, personal communication
 > from someone who implemented it, something) and you just keep
 > restating the same thing without any further argument than "b/c I say
 > so".  You say it's expected, I say it doesn't make sense to me.
 
 The closest thing to documentation is probably "An Advanced 4.4BSD
 Interprocess Communication Tutorial" [Leffler,1986], but it doesn't
 tell you when the "exceptional condition" for select (equivalent to
 POLLPRI/POLLRDBAND) goes away. It however is pretty clear on the fact
 that you cannot use it to determine when recv(MSG_OOB) will succeed.
 
 It makes sense to me to clear the OOB condition when you continue
 reading the stream beyond the mark. That's a clear indication that
 processing of OOB data has finished.
 
 It also make some sense to clear the OOB condition with some action on
 the stream instead of some action on the protocol (e.g. reading OOB
 data) because that avoids further knowledge of the protocol.
 
 So I can understand why someone made the decision for this behaviour
 a long time ago. It's not the only decision about OOB processing
 that was made and that makes it different from reading regular data.
 
 
 >   read           - returns "a"
 >   read(MSG_OOB)  - returns "b"
 >   poll           - ?
 > 
 > Are you saying it's illegal to call poll there?
 
 You can call poll here and it works as specified.
 
 
 > Are you saying it's correct for poll to return POLLPRI there when
 > there's no MSG_OOB data to read?
 
 It would be ok (but not that useful) for poll to return POLLPRI at
 almost any time. It doesn't tell you that something can be read,
 but just that an attempt to read won't block (and recv(MSG_OOB) is
 guaranteed not to block). The case where you get POLLPRI _before_
 you can read the OOB data is well documented, getting POLLPRI
 _after_ you can read OOB data isn't that different. It's even
 possible that OOB data gets lost if multiple chunks exist.
 
 This is not a good interface, just an attempt to get OOB and urgent
 data accessible to userland. It doesn't have to "make sense" and
 changing just a small aspect of it probably does more harm than
 keeping the established behaviour, in particular when there is
 almost no user of that interface.
 
 
 Greetings,
 -- 
                                 Michael van Elst
 Internet: mlelstv%serpens.de@localhost
                                 "A potential Snark may lurk in every tree."