On Thu, Apr 8, 2010 at 8:29 PM, Alexandre Julliard julliard@winehq.org wrote:
Mike Kaplinskiy mike.kaplinskiy@gmail.com writes:
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 don't see why. If you don't get POLLHUP then you can keep polling, just don't select for POLLIN once you have seen EOF. The problem with POLLHUP/POLLERR is that they can't be masked, but POLLIN doesn't have that issue.
-- Alexandre Julliard julliard@winehq.org
Shoot, I'm sorry I was confusing poll vs FD_*. You're right of course, that would work. The slight problem is that a 0 recv is not necessarily a full POLLHUP (i.e. both halves closed). So on platforms that don't signal POLLHUP/POLLERR when both halves are closed we're going to sit there and do nothing, after the first half of the socket is closed. (Are there any like this still around?) In other words we can get rid of try_event completely.
There is also a small issue that even after a full close, windows will let you call send() and succeed but with an erroneous FD_CLOSE right after. I think the best way to deal with it is just to special case it in enable_socket_event to send an error close without polling anything, if for some reason FD_CLOSE is unheld.
I'll send patches on Monday.
Mike.