> 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