Bethany, Consider moving the gdk_threads_* outside the for-loop, look for A & B changes. Also, I use these API's as ONE BIG wrapper around all gtk/gdk work from background threads.
I have found doing anything from a secondary thread with GDK/GTK to be problematic. The best guidance might be find a way to use g_idle_add() or g_timeout() along with GASyncQueue to poll background threads for ready-gui actions and have the g_timeout(gtk-thread-function()) do the work. A gtk-thread-function() runs in the same thread/task address space as GTK, so gdk_threads_leave() are not likely to cause a deadlock. James, ----- Original Message ---- From: Bethany Seeger <[EMAIL PROTECTED]> To: gtk-app-devel-list@gnome.org Sent: Wednesday, June 6, 2007 2:31:44 PM Subject: gdk_widget_modify_bg & deadlock Hello, I've got this code that seems to end up in dead lock, if I do something to the gui, while it's calling gtk_widget_modify_bg. --------- { // events is an array of widget names static GtkWidget *labels[NCONDS] = { NULL }; static unsigned int last=0xFFFFFFFF; int i; GdkColor yellow = {0,0xFFFF,0xFFFF,0}; if (!labels[0]) { /* Find our labels, the first time. */ for (i = 0; i < NCONDS; i++) { labels[i] = lookup_widget(toplevel,events[i]); } } /* Set the condition register widgets. */ if (cond != last) { gdk_threads_enter(); /* A */ for (i = 0; i < NCONDS; i++) { /* ** gdk_threads_enter(); ** A */ if (cond & (1<<i)) { gtk_widget_modify_bg(labels[i],GTK_STATE_NORMAL,&yellow); } else { gtk_widget_modify_bg(labels[i],GTK_STATE_NORMAL,NULL); } /* ** gdk_threads_leave(); ** B */ } gdk_threads_leave(); /* B */ last = cond; } } ---------- The threading has been properly initialized : g_thread_init(NULL); gdk_threads_init(); gtk_set_locale(); gtk_init(&argc,&argv); ... gdk_threads_enter(); gtk_main(); gdk_threads_leave(); The thread that's running the gtk_widget_modify_bg code was created from the main thread before it went into the gtk_main(). So I understand that I've got a main thread in gtk_main, and another thread running behind the scenes and updating the gui with user changes. If I try to change something in the gui (going to a new tab in a notebook widget) while it's running the gtk_widget_modify_bg, the gui will hang, like I've hit a deadlock condition. It happens to be the page with the widget on it that the gtk_widget_modify_bg is on. Would that be enough cause this condition? Any work arounds? The kicker is that this works fine in linux (no deadlock) -- it only deadlocks on a cross compiled windows exe. Any advice would be greatly appreciated. I don't know the ins and outs of gdk/gtk threading and can't tell if I'm doing something that's just plain wrong. Thanks, Bethany _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list