Re: gtk_events_pending() seems to spin sometimes?

[stian nixia no]

> 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