While debugging a strange problem in galeon
(http://bugzilla.gnome.org/show_bug.cgi?id=51157) we have found a bug in glib:

In short: galeon takes nearly 100% CPU time when showing modal dialogs.

Galeon start the main event processing loop. This loop is part of
the glib library and monitors a set of so called "sources" for events. Most
sources are represented by one or more filedescriptors. The events are sent
by other threads or processes and will be handled by event handlers.

Waiting for events on filedescriptors is realized by calling poll() on the 
filedescriptor set. If data is available on one filedescriptor, the
corresponding event handler of the source holding this filedescriptor is
called. 

Some event handlers are reentrant and may be called recursively others not. 
This is stated by the flag G_SOURCE_CAN_RECURSE. 

The problem is, that it is possible (and occurs in galeon) that a second
recursive mainloop is started (e.g. via gtk_dialog_run) during the
execution of an event handler which is not reentrant. If more data is
available on the corresponding filedescriptor during execution of this
second recursive mainloop, the event handler cannot be started because it
has not set G_SOURCE_CAN_RECURSE. The filedescriptor is still in the
pollset. But this will have a very nasty effect: The next call to poll will
return immediately since the waiting data is still there. As poll is called
in a loop we now have a busy loop that ends when the second main loop
finishes (i.e. the dialog gets closed).

The fix for this is rather simple: Exclude all filedescriptors of monitored
sources that will result in executing an event handler that is currently in
execution state and may not be called recursively. The included patch for
glib-2.2.1 is not very efficient but works. We think that a more efficient
solution is possible by modifying some datastructures of glib. But this
part we leave to the glib programmers.


Christian & Ron