On Thu, Apr 8, 2010 at 11:16 AM, Alexandre Julliard <julli...@winehq.org> wrote: > Mike Kaplinskiy <mike.kaplins...@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 > julli...@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.
