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
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
