Clarification on how the I/O on a socket wakes up selec()
 

Hi All,

I have been working on a select driven program which deals with around 2k sockets. While debugging a program hung I've been observed that if a RST comes on the socket, it wakes up select() with both read_set and write_set set for that socket. And if I don't close the socket after a recv() there and re-call the select() on that socket it is waking up immediately after sleeping 0 secs. And this time onwards I'm seeing only read_set set.

I even looked at the kernel TCP code but couldn't find the answer on this. Any help is highly appreciated.

Thanks a lot in advance,
jork

If the TCP session received RST flag in packet, TCP/IP stack will close the session. When recv() is called, the return value is less than 0, you have to close the TCP session.

nini,

Thanks for your reply. But I've figured out the answer myself from the code.

I'm putting here what ever I figured out thinking that it might help somebody someday.

When you call the select, it works internally by socket polling. where the poll() function checks for the sk->err and returns immediately from there, it wakes up select(). and interestingly the sk->err will be cleared after the first read itself. With the RST the err will be set to ECONNRESET or ECONNREFUSED based on the current state and the socket will be closed. Next time onwards when I call the select, the sk->err will be cleared but the socket state will be closed. Then also poll() returns and which makes the select() to wake up with only POLL_IN ie, read_set.

-jork