Re: Does Linux select() violate POSIX?

From: Nemo Publius
Date: Sat Jun 18 2011 - 14:23:21 EST

First, thank you for your reply.

On Sat, Jun 18, 2011 at 10:43 AM, Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote:
> 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:
>> ...
> Only UDP can currently do that, not TCP, if NIC did not already verified
> the checksum.
> So the answer to your question is no.

You mean the answer happens to be "no" for reading a TCP socket with
the current Linux implementation, but that is not considered part of
the interface, so the behavior could change in the future and so I
cannot depend on it?

>> According to the POSIX specification for select
>> (,
>> the answer is no:
>> ...
> We dont care, since every sane application using select() should also
> use socket in non blocking mode.

This is simply not true for any POSIX-compliant operating system.
Which in this case happens to include every Unix ever written since
the beginning of time, apart from Linux.

Put another way... The whole point of the POSIX spec is to allow me
to write portable code. If every random Unix implementation makes up
its own mind about what is "sane" and violates the spec in arbitrary
and unpredictable ways, what is the point of having a spec?

> 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
> empty.

Sounds like a kernel bug.
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