Re: gio-test

[Owen Taylor <otaylor redhat com>]

Tor Lillqvist <tml@iki.fi> writes:

> David Reid writes:
>  > In the gio-test program when an EOF is seen (0 bytes returned) then
>  > presently FALSE is returned and hence no more checks are made of the
>  > channel.  If an EOF is sent before a HUP or ERR then the program never exits
>  > as the count is never decremented.  Should these be changed to return TRUE
>  > and hence allow another check to be made for HUP or ERR to be seen?
> 
> Hmm. I think the best thing to do is to be as prepared as possible for
> GIOChannel implementations not behaving like the Unix one, and for
> some reason not ever calling the callback with G_IO_HUP set. Thus one
> probably should treat EOF identically to being called with G_IO_HUP
> set. I.e., in gio-test, call g_source_remove() and g_main_quit() if it
> was the last source.
> 
> But OTOH, to catch the case of getting called for the same source with
> both G_IO_HUP set *and* G_IO_IN set, but with an EOF condition
> returned by g_io_channel_read() (which currently happens on Win32, at
> least), we need to check the return value from g_source_remove().
> Only if we didn't try to remove an already removed source, we can
> decrement the kid counter and call g_main_quit() when it reaches zero.

Actually, even on Unix, when GLib is implementing poll with select,
an EOF is signalled by G_IO_IN with the following read being zero-length.

So, in order to write portable code, you can never rely on G_IO_HUP,
and have to specify G_IO_IN | G_IO_HUP and handle zero length
reads as meaning EOF.

                                        Owen