Re: UDP recvmsg blocks after select(), 2.6 bug?

Martijn Sipkema
2004-10-07T12:36:13Z

From: "Paul Jakma" <paul@clubi.ie>
Sent: Thursday, October 07, 2004 12:53

> On Thu, 7 Oct 2004, Chris Friesen wrote:
>
> > Actually, in the single threaded case, the state did not change. We just
> > didn't actually check the state before returning from select().
>
> Right, so our perception of state (which for all useful purposes /is/
> the state) changed - "we have data" -> "we had to throw out data due
> to bad checksum" is a change in kernel state at least, if not in the
> (now gone) data.
>
> I'm not really a kernel person. From the application POV, in the
> single-threaded case (cause the multi-threaded case is fairly
> pathological anyway), there /will/ be time between the select and the
> recvmsg, things /can/ change, and obviously they do.

That there is time between the select() and recvmsg() calls is not the
issue; the data is only checked in the call to recvmsg(). Actually the
longer the time between select() and recvmsg(), the larger the probability
that valid data has been received.

> Treating select as anything other than a useful hints mechanism is
> going to get you into trouble - just see the Stevens' example others
> gave for a long-standing example, in addition to this (sane imho)
> Linuxism.

But the standard clearly says otherwise.

> > Actually, there wasn't. The data was corrupt, therefore there was
> > no data. Nothing changed with time, as the corrupt data was already
> > present before we returned from select().
>
> Perception of state is as good as state here.

Perhaps select()'s perception of state should be made to take possible
corruption into account.

> > POSIX says that if select() says a socket is readable, a read call
> > will not block. Obviously, we are not POSIX compliant.
>
> Right, yes, that seems to be clear now.
>
> Though, I'd still say that any app that calls read/write functions
> without O_NONBLOCK set and that expects it will not block, is broken.
> Basic common sense really, never mind the fine details of POSIX on
> select(). ;)

Why would the POSIX standard say recvmsg() should not block if
it did not intend it to be used in that way?

> > There's nothing wrong with not being compliant, but it should be
> > documented and we shouldn't claim to be compliant.
>
> Right.

Wrong. IMHO it is not exactly a good thing to not be compliant on
such basic functionality.

--ms