Re: Handling Unix signals in a GTK+ application

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]