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

[David Schwartz <davids@webmaster.com>]

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

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

	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.

	DS