Re: [gtk-list] Re: gdk_threads_enter is not reentrant




Sebastian,

Reentrancy only requires code like this:

   if( gdk_lock_thread != pthread_self() ) {
       pthread_mutex_lock(gdk_lock_mutex);
       gdk_lock_thread = pthread_self();
   }
   gdk_lock_count++;

Which could not slow a GUI (or any other) application down at all.

Also, my thread locked code is way down deep.  Writing special cases
for code where gdk_threads_enter() may or may not have already been
called seems redundant.  Is that what you do for your own
multi-threaded apps?


--Noel


> Date: Wed, 08 Mar 2000 07:53:58 +0000
> From: Sebastian Wilhelmi <wilhelmi@ira.uka.de>
> 
> Hi Noel,
> 
> > 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();
> >     }
> 
> So you need 2 functions, so what?
> 
> > Could gdk_threads_enter() be made reentrant?  You should be able to
> > call it twice from the same thread without deadlock.  
> 
> Why make it slower just for this case, which happens rarely.
> 
> Bye,
> Sebastian
> -- 
> Sebastian Wilhelmi                   |            här ovanför alla molnen
> mailto:wilhelmi@ira.uka.de           |     är himmlen så förunderligt blå
> http://goethe.ira.uka.de/~wilhelmi   |
> 
> -- 
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
> 
> 



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