Re: gdk_widget_modify_bg & deadlock

[JAMES SCOTT <skoona verizon net>]

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 <seeger prosensing com>
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