Re: Handling Unix signals in a GTK+ application

[Tristan Van Berkom <tristan van berkom gmail com>]

Freddie Unpenstein wrote:

> > > That's well over 1548533 executions (I forgot to print the
> > > counter after the 10th second) of the idle callback, or
> > > 172059 calls to the idler function per second. Personally,
> > > I'd call that a busy wait.
> > >      
> > Its not a busy wait; your idle handler has never returned FALSE;
> > so whenever your application is idle (i.e. all the time) then
> > the idle handler will run; whether it be the gmain.c code or the
> > code in poll( /* timeout == 0 */ ) that decided to return directly.
> >    
>
> I wrote that test, in response to the suggestion that the Unix signal handler set a flag, and an idle handler 
> watches that flag to detect whether the signal has occured.  My idle handler incrementing a variable, is 
> symbolic of checking a flag that hasn't been tripped.
>
> Because the main loop has an idle handler, it sets a wait time on the poll() call to zero, causing it to 
> return immediately.  Effectively generating a busy-wait, via the main loop.
>
> If the idle handler returns FALSE, the idle handler will be destroyed.  If a signal then comes in, the flag 
> will be set, but never checked since that's the idle handlers job.
>
>  
Yes sure, but why would you want to use a flag... when you can just call 
g_idle_add
*from the signal hanlder*... it will be queued only once for every 
signal recieved; therefore
deffering any execution (idle handler code body) to the main loop... 
without ever
busy waiting.

Cheers,
                                -Tristan