Re: Callback on GIOChannel shutdown?

[Tor Lillqvist <tml iki fi>]

Braden McDaniel writes:
> I expected the callback associated with this watch to be called after I
> shut down data.command_channel with g_io_channel_shutdown; however, that
> doesn't appear to be the case.

You misunderstood what G_IO_HUP means. As far as I understand, it is
supposed to be a direct mapping of the POLLHUP that can be set for a
socket (or other file descriptor) after the poll() system
call. Unfortunately, what POLLHUP exactly means doesn't seem to be
that well-specified. See for instance
http://www.greenend.org.uk/rjk/2001/06/poll.html . On Unix systems
without poll(), where GLib uses select() instead, apparently G_IO_HUP
will never be used?

My understanding is that POLLHUP (and thus G_IO_HUP) means that the
kernel knows that all data has already been received by it, has been
buffered, and no more data can arrive (because the writing end of a
TCP connection has shut it down, the physical connection has been hung
up, etc). It does not mean that all data has been read by the user
process. I.e. you shouldn't stop reading from the GIOChannel just
because you get a G_IO_HUP callback. Stop reading only when you get a
definite EOF indication (G_IO_STATUS_EOF or zero-length read() or
recv()). You can stop polling (watching) the channel, though, as
everything there will be is already available in the kernel without
wait, so just read it.

However, due to the vagaries of POLLHUP implementations on different
Unixes, not to mention the general difficulty in emulating poll()
-style behaviour on Windows, my personal opinion is that it might be
best to to not even try handling G_IO_HUP. Just handle G_IO_READ.

> Is there some other way I can receive notification that the channel has
> been shut down?

That the channel has been shut down by your own code? Well, you just
have to handle that appropriately in your own code, then. As
g_io_channel_shutdown() calls the close method of the GIOChannel, you
won't get any more callbacks from it.

--tml