Re: Handling Unix signals in a GTK+ application

[Soeren Sandmann <sandmann daimi au dk>]

Chris Vine <chris cvine freeserve co uk> writes:

> That's not right.  Idle handlers do not busy wait.  They do trigger 
> invocations of the event loop at indeterminate intervals.  They are also very 
> common (if you don't want to communicate with the glib event loop from other 
> threads with a pipe, you are likely to end up with using a GAsyncQueue object 
> and an idle handler).

The idle handlers work like this in glib:

   Whenever the event loop doesn't have anything else to do, it calls
   the idle handler over and over until it either returns FALSE or is
   removed by g_source_remove().

So if you use an idle handler to check for a signal bit, then you are
effectively doing a busy wait. The idle handlers that gtk+ uses
internally are generally one-shot handlers that always return FALSE,
so they don't cause 100% CPU use.

I suspect you think the idle handlers have the semantics of an 'idle
event', ie., something that gets called once every time the event loop
would otherwise call poll(). But that is not the case.


Soren