Re: [gtk-list] gdk_threads_enter is not reentrant

[Noel Burton-Krahn <noel burton-krahn com>]

The code example I have is fairly long.  Let me describe it.  I have a
worker thread which computes a GdkPixmap.  A user event can cancel the
thread.  So, the computed pixmap can be deleted:

    (a) by the worker thread when it finishes.
    (b) immediately in the callback function in gtk_main().

In both cases, I should call gdk_threads_enter() to protect calls to
gdk.  However, in case (b) gdk_threads_enter() has already been called
by gtk_main().  So, when I call it again it deadlocks.

Another example: I have a utility function update_progress() which
updates a GdkProgress.  Again, it has to use gdk_threads_enter() and
it is called from both a thread and a callback.  The callback hangs
because gdk_threads_enter() is not reentrant.

gdk-1.2 has a lot of bugs with threads.  For instance, it hangs after
gtk_main_quit().  It's easy to make gdk_thread_enter() reentrant (my
code is below), so why not do that while fixing the other thread bugs?

--Noel




> Date: Wed, 08 Mar 2000 08:54:02 -0000 (GMT)
> From: Trog <trog@gtk.org>
> 
> I don't quite see the problem. It shouldn't need to be reentrant.
> Could you give an example of a situation which requires reentrancy?
> 
> Anyway, you could always code it in your application using a mutex.
> 
> -tony
> 
> 
> 
> On 06-Mar-2000 Noel Burton-Krahn wrote:
> > 
> > I have a piece of code which may be run from a GTK callback or
> > within
> > a thread outside of gtk_main().  The problem is that
> > gdk_threads_enter() is not reentrant.  It locks up if I call it
> > within
> > a callback function.  If I omit the lock, I could trash GTK
> > internals.
> > 
> >     MyData::destroy() {
> >       gdk_threads_enter();   // hangs if called withing a callback
> >       free_some_gdk_data();  // but I need to lock to protect GTK
> >       gdk_threads_leave();
> >     }
> > 
> > Could gdk_threads_enter() be made reentrant?  You should be able to
> > call it twice from the same thread without deadlock.  How about
> > something like this?
> > 
> >     pthread_mutex_t gdk_lock_mutex;
> >     int             gdk_lock_count;
> >     pthread_t       gdk_lock_thread;
> > 
> >     gdk_threads_enter() {
> >       if( gdk_lock_thread != pthread_self() ) {
> >           pthread_mutex_lock(gdk_lock_mutex);
> >           assert(gdk_lock_count == 0 && gdk_lock_thread == 0);
> >           gdk_lock_thread = pthread_self();
> >       }
> >       gdk_lock_count++;
> >     }
> > 
> >     gdk_threads_leave() {
> >       assert(gdk_lock_count > 0 && gdk_lock_thread ==
> pthread_self());
> >       gdk_lock_count--;
> >       if( gdk_lock_count == 0 ) {
> >           pthread_mutex_unlock(gdk_lock_mutex);
> >           gdk_lock_thread = 0;
> >           gdk_lock_count = 0;
> >       }
> >     }
> > 
> > --Noel
> > 
> > 
> > -- 
> > To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com <
> > /dev/null
> 
> ---
> E-Mail: trog@gtk.org
> Your picture of the world often changes just before you get it into focus.
> 
> Go Bezerk! http://www.gtk.org/~trog
>