Re: kernel 2.4.18 - select() returning strange value

David Schwartz (davids@webmaster.com)
Sat, 8 Jun 2002 18:57:49 -0700


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/