On Thu, Apr 8, 2010 at 11:16 AM, Alexandre Julliard julliard@winehq.org wrote:
Mike Kaplinskiy mike.kaplinskiy@gmail.com writes:
But I see your point that perhaps it doesn't belong in the main loop when one of the halves gets closed. I guess we can keep sock_try_event around but only use it when the socket has been removed from the main loop. I'll also add detection of half-closed connection and drop that event if the other half hasn't hung up yet. Sadly looks like MacOS will be left out of that detection since it reports POLLIN|POLLHUP for everything.
Does that sound good?
I think sock_try_event shouldn't even do a poll() at all. Once we have received POLLHUP there's no point in continuing to poll. All it should have to do is try a MSG_PEEK read to detect EOF for platforms where that triggers a POLLHUP. All other cases should be handled by the main loop.
-- Alexandre Julliard julliard@winehq.org
This won't work for implementing half-closed sockets. If we have only the read half is closed, we will get POLLIN/0 recv indefinitely if we keep polling (not POLLHUP). If we remove it from the loop, we have to keep polling (once in a while, i.e. when an enable_socket_event gets through) until we get a POLLHUP/POLLERR which signals the other half is closed. On some platforms this won't work, but they will jump to a full close automatically (i.e. POLLHUP right away). The problem now is that if we receive a shutdown, we will spam FD_CLOSE on every successful send.
I suppose if we don't care to send more than 1 FD_CLOSE (which windows does do), we can just remove the socket from the loop and be done with it. I don't know if any apps actually depend on receiving a second FD_CLOSE after the remote end has sent a shutdown.
Should we just implement the 1 FD_CLOSE behavior and then if any regressions relating to it pop up bring back try_event?
Mike.