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

[Andries Brouwer]

On Wed, Oct 06, 2004 at 02:18:23PM -0600, Chris Friesen wrote:

> In any case, the current behaviour is not compliant with the POSIX text 
> that Andries posted.  Perhaps this should be documented somewhere?

For the time being I wrote (in select.2)

BUGS
       It has been reported (Linux 2.6) that select may report  a
       socket  file descriptor as "ready for reading", while nev-
       ertheless a subsequent read  blocks.  This  could  perhaps
       happen  when  data  has  arrived  but upon examination has
       wrong checksum and is discarded. Thus it may be  safer  to
       use non-blocking I/O.

(I have not yet investigated, just read the lk posts. Does this
really happen? All kernel versions? Is this the explanation for
the reported behaviour?)

> Alternately, how about having the recvmsg() call return a zero, and (if 
> appropriate) the length of the name set to zero?  This appears to comply 
> with the man page for recvmsg().

Returning 0 for a read signifies end-of-file. Not what you want.

Andries
-
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/