Daniel Walker diwalker@earthlink.net writes:
To improve on this patch we could only do the FIONREAD if the sock is in a non-blocking state. That's the only time that doing the FIONREAD would be an advantage. Also we wouldn't need to worry about screwing up blocking sockets. Even further, we could only do the FIONREAD if socket is non-blocking and looking for an FD_CLOSE event.
Using FIONREAD is simply not an option, it cannot be made reliable. A possibility to detect EOF could be a recvmsg with MSG_PEEK flag, though you should probably verify first that it behaves as expected.
Alexandre Julliard wrote:
Daniel Walker diwalker@earthlink.net writes:
To improve on this patch we could only do the FIONREAD if the sock is
in a non-blocking state. That's the only time that doing the FIONREAD would be an advantage. Also we wouldn't need to worry about screwing up blocking sockets. Even further, we could only do the FIONREAD if socket is non-blocking and looking for an FD_CLOSE event.
Using FIONREAD is simply not an option, it cannot be made reliable. A possibility to detect EOF could be a recvmsg with MSG_PEEK flag, though you should probably verify first that it behaves as expected.
How is it unreliable? Why is MSG_PEEK more reliable? I'm not opposed to using MSG_PEEK , just curios.. Another issue is why doesn't poll() give us a POLLHUP? That would be ideal, get poll() to work the way we need it too.
Daniel Walker