Re: Handling Unix signals in a GTK+ application
- From: Tristan Van Berkom <tristan van berkom gmail com>
- To: fredderic excite com
- Cc: gtk-app-devel-list gnome org
- Subject: Re: Handling Unix signals in a GTK+ application
- Date: Thu, 16 Mar 2006 15:40:08 -0500
Freddie Unpenstein wrote:
Yes sure, but why would you want to use a flag... when you can just call
*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...
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.
] [Thread Prev