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
-
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/
This archive was generated by hypermail 2b29 : Tue Jul 23 2002 - 22:00:41 EST