Re: Win32 Glib 2.8.x g_io_channel issues (receiving window messages on socket io channel)

[Tor Lillqvist <tml iki fi>]

(Follow-up to a message in gtk-app-devel-list, see there for
background.)

 > Anyway, the handling of [shutdown by the other end] sockets in
 > giowin32.c does not emulate exactly how it works out on Unix. On
 > Win32, the event for a socket (see MSDN docs for WSAEventSelect()
 > and WSAEnumNetworkEvents()) will fire with FD_CLOSE only once after
 > the remote end has shut down the connection.

 > g_io_win32_check() currently works in such a way that the dispatch
 > function will be invoked with G_IO_HUP only once after that
 > (additionally G_IO_IN, if FD_READ also was set). If the user callback
 > then reads less data than available, the callback will continue to be
 > invoked with just G_IO_IN.

 > After there is no longer any data to read, the event will not fire,
 > and no more callbacks will be invoked. I.e., no more callbacks with
 > (only) G_IO_HUP. On Unix, apparently a callback will be called
 > repeatedly with G_IO_IN as long as the socket is polled if the remote
 > end has shut down the connection?
 > 
 > giowin32.c presumably should be fixed at least so that the G_IO_HUP
 > indication will "stick". After a FD_CLOSE has been seen, G_IO_HUP
 > would always be set in combination with G_IO_IN in the callbacks.
 > 
 > Maybe even the socket's event should be forced to the signalled state
 > after a FD_CLOSE is received, so that g_poll() would continuously
 > notice it, and the callback continuously invoked with G_IO_HUP, until
 > the watch is removed? Hmm.

What semantics does GLib promise with respect to G_IO_IN vs. G_IO_HUP?
Or what can apps reasonably expect? In what cases does poll() set
POLLHUP on Unix (when polling sockets)?  After the remote end has
shutdown for writing, or closed a TCP connection, will the callback
from giounix indicate G_IO_HUP, or just G_IO_IN?

Some slight experimentation would indicate the latter, is this
correct? So should giowin32.c even be changed so that after noticing a
FD_CLOSE event on a socket, the check method would always set *both*
G_IO_IN and G_IO_HUP? There are presumably lots of apps that don't
check for G_IO_HUP, but instead just try to read() or recv(), and
deduce EOF if this fails?

(GdkInputCondition doesn't even have any separate IN and HUP, just
READ.)

--tml