Re: Handling Unix signals in a GTK+ application

[Gus Koppel <gtk spamkiller bytechase cx>]

Chris Vine wrote:

> On Saturday 11 March 2006 22:36, Thomas Okken wrote:
> > > [Using a pipe] is generally the best way of dealing
> > > with asynchronous (Unix) signals, but for simple
> > > cases another approach is just to set a flag of type
> > > volatile sig_atomic_t in the Unix signal handler,
> > > and then check and act on the status of the flag in
> > > the glib event loop with an idle handler set up with
> > > g_idle_add().
> >
> > The downside of that approach is that you have to
> > busy-wait on that flag, while the pipe approach allows
> > the application to be completely idle (and still have
> > fast response to the signal)... I went with the pipe
> > approach; using the sample code referred to by another
> > poster, it turned out to be pretty easy.
>
> 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.

However, if you know your application belongs to the majority of GTK+
applications, that is, it stays in the outermost main loop, spending
most of its time actually being idle, then using the idle handler may be
appropriate. But as explained, it's not quite as "fail-safe" as pipes.