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

On Mon, 22 Jul 2002 19:57:49 -0700 (PDT), David S. Miller wrote:
>From: Peter Niemayer <>
>Date: Mon, 22 Jul 2002 12:43:14 +0200

>If one process tries to read non-blocking from a tcp socket (domain sockets
>fine), and another process sends the reading process signals, then
>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

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

EAGAIN is the correct value unless the read/recv was itself interrupted by a
signal. However, the 'select' should not indicate that the socket is readable
unless there is something to read (or an error, or whatnot). When 'select' is
interrupted by a signal, select should return EINTR.

My guess is that select did return EINTR, but for some reason your
application examined the fd sets anyway. So the bug is in not ignoring the fd
sets when select returns an error, which is an application issue.

Most likely, 'select' never got around to touching the fd sets at all.


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:27    [W:0.067 / U:1.152 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site