Answer to: What causes GLib I/O Channels operations to use up 100% CPU in GTK+ app.?

[Daniel Yek <dyek real com>]

Thanks for responding. I sent out a reply in the afternoon, but it was 
waiting for approval due to the way I sent it.

I was: [Moving gtk-app-devel-list gnome org to BCC.]

Similar response inline...

At 09:36 PM 10/12/2006, tomas tuxteam de wrote:

> On Thu, Oct 12, 2006 at 02:41:06AM -0700, Daniel Yek wrote:
> >
> > At 02:36 AM 10/12/2006, Daniel Yek wrote:
> > >
> > >Could somebody enlighten me why after an I/O Channel operation
> > >(g_io_channel_shutdown() here), the GTK+ program started to use up 
> 100% CPU?
> > >
> > >Is it monitoring something? Do I need to undo g_io_add_watch() somehow?
> > >What operation is needed to not get into such situation?
>
> I just browsed through your program (so take my rablings with a grain of
> salt), but a couple of things strike me:
>
>   - who is writing to the writing end of the pipe? Note that writing
>     into and reading from the same pipe is not recommended (although for
>     a small test program and if you are writing small amounts of data
>     you might get away with iti ;-)
>
>   - One thing which happens easily is: when the writing side closes, the
>     reading side gets a read with 0 bytes (as a "signal" of EOF). In a
>     select() (and that is what is at GTK's core dispatching things),
>     this file descriptor is considered ready (but yielding zero bytes).
>     I don't know whether GIOChannel wraps this (I doubt it can), but this
>     is the typical cause for "spinning" in such programs.
>
> Uh. I don't know if I was clear.

Figured that out myself.

1. Closing the write-end of the pipe caused GIOConditoin of G_IO_HUP being 
generated when being polled. Failing to intercept and react to it by 
removing the Channel watch causes infinite GIOConditoin of G_IO_HUP 
"notification attempt" and hence 100% CPU usage. There should be an assert 
to guard this infinite loop in channel monitoring.

2. Closing the read-end of the pipe caused GIOConditoin of G_IO_NVAL when 
being polled. Failing to intercept and react to it by removing the Channel 
watch causes infinite GIOConditoin of G_IO_NVAL "notification attempt".

3. Shutting down the I/O Channel without removing Channel Watch again 
causes condition #2 above.

These seem like rough edges to me.

Is there any developer willing to insert asserts or implement default 
handling where appropriate?

Thanks.


--
Daniel Yek




> Regards
> - -- tom