> I wonder what g_usleep does if it is called from inside an idle
> function.  Could that lead to recursion since the idle functions is
> called when the cpu has idle time?

Idle functions in Glib are basically a kind of timer, with a zero timeout, and 
a very low priority.  The main loop does its tricks with file handles (GUI 
events, new data to read from an internet connection, etc.), and then picks up 
the most important timeout (the one with the highest priority), that also 
happens to have expired (which is why timeouts aren't guaranteed to be called 
on time).  Idle functions are simply timeouts with a very low priority (so 
everything else will happen first), and a timeout of zero (so it's immediately 
qualified for execution, just as soon as the main loop is done with everything 
else, and finally gets around to looking at it).

Setting any kind of timer won't be recursion because it won't happen until the 
next time through the main loop anyhow.  So even if it was timer-based, it 
still wouldn't be recursion.

But then g_usleep(), like most sleep() functions, is usually of the blocking 
variety anyhow.  As the Glib documentation states, the whole thread stops for a 
brief period.  This will usually be a kernel call or perhaps even a busy loop.  
But in either case, nothing can happen in the process until the sleep finishes, 
so it will never be recursive with anything (unless you could other threads 
executing).


(ps. If I got anything terribly wrong, please let me know! ;) )


Fredderic

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Reply via email to