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
-
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:42 EST