On Sun, Mar 27, 2005 at 01:26:26PM +0200, stian@xxxxxxxx wrote:
> > I imagine select() doesn't block too long because my program is keeping
> > the cpu so busy. Is it possible I'm screwing up my environment somehow
> > that's causing this breakage? Am I using gtk_events_pending()
> > incorrectly? What should I look for?
>
> Is this a threaded application? If so, you should check the
> gdk_thread_leave/gdk_thread_enter balance and usage.
how about this for a possibility...
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.
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 }
so, many threads are allowed to run. I wonder... my signal handler
jumps into code that assumes threads have been turned off. I'm using
sigaction() to set my handler, so I should never have more than one of
the same handler running. and it runs very quickly, compared to the
amount of time between signals. hm... maybe I'll test for that
anyway.
but... maybe ... if my handler runs in the middle of what is actually
a critical section of some other gtk code, maybe running asynchronous
gui updating and event processing like this would cause problems. it
sounds likely.
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.
Thanks,
- Ben
_______________________________________________
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
