Re: execution of timers from other callbacks

["Emmanuel Rodriguez" <emmanuel rodriguez gmail com>]

Hi zentara!

On Wed, Dec 17, 2008 at 6:00 PM, zentara <zentara1 sbcglobal net> wrote:
> Hi,
> 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.