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

Chris Friesen
2004-10-07T07:12:17Z

Paul Jakma wrote:
> On Wed, 6 Oct 2004, Richard B. Johnson wrote:
>> thing --not. Select must return correct information.
> It does, it's just state that select() reported on changed by the time
> user called recvmsg.

Actually, in the single threaded case, the state did not change. We just didn't
actually check the state before returning from select().

>> When a function call like select() says there are data available,
>> there must be data available, period.

> There was, but there wasnt when recvmsg() was called. Time changes things.

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().

> Any application that expects socket read not to block should set
> O_NONBLOCK.

POSIX says that if select() says a socket is readable, a read call will not
block. Obviously, we are not POSIX compliant.

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

Chris