RE: [gtk-list] gdk_threads_enter is not reentrant




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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]