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

[Chris Friesen]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/