lkml.org 
[lkml]   [2004]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: UDP recvmsg blocks after select(), 2.6 bug?
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.194 / U:0.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site