Re: Handling Unix signals in a GTK+ application

[Chris Vine <chris cvine freeserve co uk>]

On Sunday 12 March 2006 10:49, Gus Koppel wrote:
> Chris Vine wrote:

[snip]

> > 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 main problem I see with idle handlers is that there may be
> application types on which they rarely or never get triggered, simply
> because the app doesn't go idle. This is commonly the case for games and
> multimedia applications, which may consume all CPU power there is,
> possibly generating their own GTK+ signals for redrawings or other tasks
> all the time, or other sorts of applications which perform long
> calculations and may see the main loop only via gtk_main_iteration() if
> there are events pending. Such applications wouldn't enter idle state
> (hence not triggering the idle handler) for potentially long periods. On
> the other hand, news from a pipe could still be received and processed
> nearly instantaneous, as they have higher priority than idle events.

If the issue is simply one of competition in the main event loop then you can 
bump up the priority of the idle handler by setting it with 
g_idle_add_full().  GDK uses idle handlers for redrawing operations, and GTK+ 
uses idle handlers for widget resizing and a number of other things.  If you 
give your idle handler a priority G_PRIORITY_HIGH_IDLE it will have a higher 
priority than these GTK+/GDK operations.  Alternatively you can set a 
timeout, which has even higher priority (the same priority as given by GDK to 
events from the X server).

If you are posing a situation that, because of non-GTK+ processing in a 
program, the main event loop in the program isn't being run sufficiently 
often (or only on calling gtk_main_iteration()), then you are wrong in 
thinking that using a pipe (or indeed any priority setting) will solve the 
problem.  The execution of the callback which is invoked when the pipe has 
something to be read is just an event in the program event loop, like any 
other.  The GSource object for a GIOChannel object does have a higher 
priority than G_PRIORITY_HIGH_IDLE (by default it has the same priority as 
does a timeout by default), but that would only be an advantage in getting in 
first if there were lots of events pending, and no advantage even then if all 
you are doing is, for example, sending requests to GTK+ via a pipe which will 
result in redraws, rather than wanting to extract chunks of data from a pipe 
or socket supplied by another process in order to do something meaningful 
with it.

Using a pipe to signal infrequent events is in theory marginally more 
efficient because processing time is not taken up iterating through the event 
loop at intervals checking flags or event queues (or whatever), particularly 
if there are lots of different events which might need to be checked for, and 
it will slightly assist the OS's scheduler in allocating processor time.  
However, you will not notice this in practice, particularly in a GTK+ program 
because of all the other things (including running idle handlers) that GDK 
and GTK+ will be doing.  Going back to your original point, it is definitely 
not a "busy wait".

Chris