[PATCH 01/10] server: allow polling for no events in set_fd_events

[Mike Kaplinskiy]

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