Re: Does Linux select() violate POSIX?

From: Eric Dumazet
Date: Sat Jun 18 2011 - 13:43:17 EST

Le samedi 18 juin 2011 Ã 10:06 -0700, Nemo Publius a Ãcrit :
> Suppose I have a file descriptor referencing a TCP/IP socket in blocking mode.
> Suppose select() reports that the descriptor is ready for reading.
> If I then call recv() on that descriptor, can it _ever_ block?
> According to the Linux select man page
> (, the answer is yes:
> "Under Linux, select() may report a socket file descriptor as "ready
> for reading", while nevertheless a subsequent read blocks. This could
> for example happen when data has arrived but upon examination has
> wrong checksum and is discarded. There may be other circumstances in
> which a file descriptor is spuriously reported as ready."

Only UDP can currently do that, not TCP, if NIC did not already verified
the checksum.

So the answer to your question is no.

> According to the POSIX specification for select
> (,
> the answer is no:
> "A descriptor shall be considered ready for reading when a call to an
> input function with O_NONBLOCK clear would not block, whether or not
> the function would transfer data successfully. (The function might
> return data, an end-of-file indication, or an error other than one
> indicating that it is blocked, and in each of these cases the
> descriptor shall be considered ready for reading.)"
> There are only three possibilities:
> 1) I am mis-reading the POSIX spec.
> 2) The Linux select() man page is wrong.
> 3) Linux select() violates the POSIX spec.

We dont care, since every sane application using select() should also
use socket in non blocking mode.

Between time select()/poll() says 'OK you can go', and time you enter
kernel, conditions might have changed. For example, maybe kernel memory
is not available and a send() would _block_, even if socket queue is

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at