[lkml]   [2002]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: read/recv sometimes returns EAGAIN instead of EINTR on SMP

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

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

 \ /
  Last update: 2005-03-22 13:22    [W:0.100 / U:2.984 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site