kernel 2.4.18 - select() returning strange value
Hello everyone.
Please CC: me on replies
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.
Details: I first noticed, when trying to install the perl module Net::Telnet, that the select test was failing. Running strace on the test program, I determined that select() was returning an unexpected value.
I wrote a simple C program to duplicate this behavior, and got the same results.
sock = socket(AF_INET, SOCK_STREAM, 6);FD_ZERO(&rfds);FD_SET(sock, &rfds);
tv.tv_sec = 0; tv.tv_usec = 0;
retval = select(sock+1, &rfds, NULL, NULL, &tv);
Produced these strace lines:
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 select(4, [3], NULL, NULL, {0, 0}) = 1 (in [3], left {0, 0})
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.
I've gotten this result on kernel 2.4.18, and someone confirmed the same result on 2.4.19-pre7. A user with 2.2.19 ran my test program and got a return value of 0, which is what I would expect the return value to be.
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.
Any insight into this would be much appreciated. Thanks in advance.
Signature · 2 lines
Regards, Jake mailto:[email protected]
Quoted 3 lines · Jacob Cohen
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.
Quoted 4 lines
According to what I've read in the man pages for
select()andsocket(), a nonconnected socket should be unreadable, and thereforeselect()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.
Quoted 4 lines
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