On Fri, 7 Jun 2002 13:09:05 -0700, Jacob Cohen wrote:
>Summary: when calling select() on a set of file descriptors containing
>only the descriptor of a non-connected stream socket, select() returns
>1 and marks the FD set as if data were waiting on the socket.
This seems correct to me. A read or write will not block and there is
nothing to wait for.
>According to what I've read in the man pages for select() and
>socket(), a nonconnected socket should be unreadable, and therefore
>select() should timeout and return 0. I cannot figure out why it is
>returning 1.
Because the socket is ready for read. If a read were attempted immediately,
it would not block. If a read would result in an error other than
'EWOULDBLOCK', the socket is ready to be read.
>Has something changed in the kernel or the way the select() syscall
>behaves on a nonconnected socket that I should be aware of? I cannot
>find anything relevant in the recent change logs, but I am probably
>missing something.
I'm guessing the previous erroneous behavior was fixed. When you 'select' on
an unconnected socket, what do you expect 'select' to wait for?
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 : Sat Jun 15 2002 - 22:00:13 EST