> I'm using a (traditional POSIX) signal handler to run this code. I use
> setitimer() to tell the OS to interrupt my application with a SIGALRM
> signal after something like 1 second, every second.
Naughty boy :-p setitimer can be very nasty if the signal handler
interacts with gtk code. However, you can do it more nice by doing a
trylock() call and just exit silenty if that fails. Glib has a
timer-callback, but it requires that you are within the gtk_main context
when it times out, else it will linger until it does, and then send the
g_signal.
> I see that gtk_events_pending() looks like this:
>
> 1031 gtk_events_pending (void)
> 1032 {
> 1033 gboolean result;
> 1034
> 1035 GDK_THREADS_LEAVE ();
> 1036 result = g_main_context_pending (NULL);
> 1037 GDK_THREADS_ENTER ();
> 1038
> 1039 return result;
> 1040 }
GDK_THREAD_LEAVE() and GDK_THREAD_ENTER are macroes that tests if
threading is enabled or not before lock/unlock. You can look up those
macroes and check if threading is enabled by poking the functions it uses.
> this is unfortunate though. my perl handler can block for a long time
> and I'd rather not wait for it to return before updating my form. maybe
> I should try using threads instead.
Use two threads. One for perl and one for the rest of the program. Unless
you are able to make the perl-script async instead.
Stian Skjelstad
_______________________________________________
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
