Chris Vine <[EMAIL PROTECTED]> writes: > That's not right. Idle handlers do not busy wait. They do trigger > invocations of the event loop at indeterminate intervals. They are also very > common (if you don't want to communicate with the glib event loop from other > threads with a pipe, you are likely to end up with using a GAsyncQueue object > and an idle handler).
The idle handlers work like this in glib: Whenever the event loop doesn't have anything else to do, it calls the idle handler over and over until it either returns FALSE or is removed by g_source_remove(). So if you use an idle handler to check for a signal bit, then you are effectively doing a busy wait. The idle handlers that gtk+ uses internally are generally one-shot handlers that always return FALSE, so they don't cause 100% CPU use. I suspect you think the idle handlers have the semantics of an 'idle event', ie., something that gets called once every time the event loop would otherwise call poll(). But that is not the case. Soren _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
