Re: execution of timers from other callbacks

Hi zentara!

On Wed, Dec 17, 2008 at 6:00 PM, zentara <zentara1 sbcglobal net> wrote:
I saw something on the gtk2-c list that got me thinking. :-)

In the following code, a timer is placed in a button callback,
but without a "non-blocking-delay" or a forced-loop-update
in the for loop, the timer dosn't run until the button callback
returns......even with very large numbers in the for loop.

So is this a rule? That timeouts and idle_adds won't be scheduled
until the callback they are in finishes, or you force the
eventloop to check itself?
Where is this documented? Or is it suposed to be obvious? :-)

Usually a GTK application has a single 'thread/process' executing the
main code which enters a main loop and waits for events from the X
server and other sources (i.e. I/O listeners added with
Glib::IO->add_watch). As soon as there's a response for an event the
corresponding callback will be called from the main thread. That's why
callbacks have to be fast otherwise the main GUI seems to be frozen.
Timeouts (including the "non blocking") also obey to this rule. Their
execution is under the responsability of the main thread.

As far as I know, starting a second main loop doesn't give another
execution thread but just another loop that will process events. I
think that the possibility to start another main loop exists in order
to make the life of dialogs easier.

Emmanuel Rodriguez.

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