Re: [gtk-list] Re: can timers interrupt my code?

[Owen Taylor <otaylor redhat com>]

Paul Barton-Davis <pbd@op.net> writes:

> >Do timeout callbacks interrupt drawing code?  I mean, in my configure
> >callback (e.g.), do I need to worry about the drawing code being
> >interrupted by a timeout which shares some data?
> >
> >Same for input functions?
> >
> >GGAD isn't explicit on this (sorry if I missed it), but it describes
> >both of these under 'The Main Loop', which implies that they are run
> >from the main loop, and not completely asynchronously.
> 
> They are called completely synchronously. the glib main loop simply
> sets the select/poll timeout so that we will return at the "right"
> time if there are no input events. By the same token, if drawing code
> or other event-driven code take too long to return control to the main
> loop, then your timeout function won't be called "on time".
> 
> This is one reason why using glib-based timeouts is inadequate if
> timer resolution is important to you. In that case, you need to use,
> for example, sigitimer(), and that will cause the execution of a
> function that will interrupt drawing code. I tend to use 
> 
>             GDK_THREADS_ENTER();
>             .
> 	    ... body of SIGALRM handler ...
> 	    .
> 	    GDK_THREADS_LEAVE();
> 
> in such code, even if I don't think I'm going to trample on any
> glib/gdk/gtk functions or variables.

Using GDK_THREADS_ENTER()/LEAVE() in a non-threaded application
is not going to work.

GDK_THREADS_ENTER()/LEAVE() do nothing if you haven't called
g_thread_init().

If you have called g_thread_init(), then imagine if the main
thread is holding the GDK lock when your itimer is called.
Then your itimer routine is going to block waiting for the
main thread to release the lock, but the main thread isn't
running, so that lock will never be released.

Regards,
                                        Owen