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, [EMAIL PROTECTED] 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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
