[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/54435: reading TCP urgent data with MSG_OOB doesn't clear poll(2) status
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>
Subject: Re: kern/54435: reading TCP urgent data with MSG_OOB doesn't clear
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.
Michael van Elst
"A potential Snark may lurk in every tree."
Main Index |
Thread Index |