Re: issue with gnome-dictionary and io channels

[Aaron Solochek <aarons-gnome aberrant org>]

Tristan Van Berkom wrote:
> On Thu, 16 Dec 2004 11:01:32 -0600, Aaron Solochek
> <aarons-gnome aberrant org> wrote:
> [...]
>
> > In the above situation, the "have data on the socket to read" callback
> > is fired, but g_io_channel_read_chars() reads 0 bytes, and returns
> > without an error.  The flag triggering the callback is either not reset
> > by the read, or is triggered again for some unknown-to-me reason,
> > resulting in the callback firing and failing to read in an infinite loop.
> >
> > Does anyone have any insight into the internals of this?  I've tried
> > playing with the underlying unix file descriptor, opening it with
> > O_ASYNC and watching for the SIGIO in main(), but I think its being
> > disabled by glib.  I can manually send a SIGIO to the process, and that
> > is detected fine.
>
>
> Looks like a hangup, I'm not sure if people in general are using a
> G_IO_HUP condition handler or not, but the way I usualy detect
> a hangup is by reading 0 bytes when select tells me that there
> is data to read on the socket.

The handler that's getting fired is for G_IO_IN.  Why would that be 
continuously triggered when the condition is actually G_IO_HUP?  I tried 
checking for G_IO_HUP inside the handler (I added it to the condition to 
trigger on) with g_io_channel_get_buffer_condition and just by manually 
printing the condition variable passed in. 
g_io_channel_get_buffer_condition always returns 0, and the passed in 
condition always is 1 (G_IO_IN).

Is this network situation I'm experiencing really all that unusual that 
it goes basically undetected by the standard libs?  Why wouldn't SIGPIPE 
be sent here?

-Aaron