Re: read/recv sometimes returns EAGAIN instead of EINTR on SMP

Hello!

>    If one process tries to read non-blocking from a tcp socket (domain sockets work
>    fine), and another process sends the reading process signals, then sometimes
>    select() returns with the indication that the socket is readable,
>    but the subsequent read returns EAGAIN - instead of EINTR which
>    would have been the correct return code. This only happenes on SMP
>    machines.
> 
> I think EAGAIN is the correct return value.  This behavior has been
> there since the stone ages of TCP and I remember Alan specifically
> auditing all of this stuff long ago wrt. POSIX compliance.

However, I suspect this is bug. At least this behavior is absolutely
unjustified and unintelligible. If socket has something to read,
we have no reasons to interrupt.

                /* We need to check signals first, to get correct SIGURG
                 * handling. FIXME: Need to check this doesnt impact 1003.1g
                 * and move it down to the bottom of the loop
                 */

First, the first sentence contradicts to the second. The second is right,
the first sounds strange.

Second, I never understood what is the problem with SIGURG.
That's why it lives untouched.

Alexey