Messages in this thread | | | Date | Wed, 6 Oct 2004 22:38:18 +0200 | From | Andries Brouwer <> | Subject | Re: UDP recvmsg blocks after select(), 2.6 bug? |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |