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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

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

From: Robert Elz <kre%munnari.OZ.AU@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: Thu, 08 Aug 2019 07:32:10 +0700

     Date:        Thu, 8 Aug 2019 01:51:52 +0300
     From:        Valery Ushakov <uwe%stderr.spb.ru@localhost>
     Message-ID:  <20190807225152.GB1102%pony.stderr.spb.ru@localhost>
 
   | But I think TCP urgent data is the only "out-of-band" thing we have,
   | so it has to be the guinea pig for this out of necessity.
 
 It is now (unless sctp provides something different than TCP, I don't
 know sctp at all) - there used to be OSI and X.25 implementations for
 BSD though, and those really provide OOB data, for which recv(MSG_OOB)
 is the right interface.
 
   | And since we do provide recv(MSG_OOB) we might as well provide
   | non-buggy poll to go with it.
 
 Again, Michael says that what we have isn't buggy.   From the example in
 the tutorial (which remains in rlogin to this day) the method used for
 urgent data using recv(MSG_OOB) is to read (using recv() or read()) until
 SOICATMARK returns true, and then do the recv(MSG_OOB).   Have you tried
 that to see if that works?   It is not what your test program did.
 
 I also asked (earlier) what FreeBSD/MacOS/Solaris do in this area - that
 linux is different would not be all that strange.  It often is.
 
 kre