Hi folks,
I would like to know if the following scenario is real?!
- select() (RD) on non-blocking TCP socket says that the socket is ready
- following recv() would return EWOULDBLOCK despite the call to select()
Hi folks,
I would like to know if the following scenario is real?!
It's possible, but only in a situation where you have multiple threads/processes trying to read from the same socket.
For recv()
you would get EAGAIN
rather than EWOULDBLOCK
, and yes it is possible. Since you have just checked with select()
then one of two things happened:
select()
and recv()
.It is possible in a multithreaded environment where two threads are reading from the socket. Is this a multithreaded application?
If you do not call any other syscall between select() and recv() on this socket, then recv() will never return EAGAIN or EWOULDBLOCK.
I don't know what they mean with recv-timeout, however, the POSIX standard does not mention it here so you can be safe calling recv().
I am aware of an error in a popular desktop operating where O_NONBLOCK
TCP sockets, particularly those running over the loopback interface, can sometimes return EAGAIN
from recv()
after select()
reports the socket is ready for reading. In my case, this happens after the other side half-closes the sending stream.
For more details, see the source code for t_nx.ml
in the NX library of my OCaml Network Application Environment distribution. ([link])
Though my application is a single-threaded one, I noticed that the described behavior is not uncommon in RHEL5. Both with TCP and UDP sockets that were set to O_NONBLOCK (the only socket option that is set). select() reports that the socket is ready but the following recv() returns EAGAIN.
On Linux it's even documented that this can happen, as I read it.
See this question:
http://stackoverflow.com/questions/858282/spurious-readiness-notification-for-select-system-call