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 <[EMAIL PROTECTED]>
>
> 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:[EMAIL PROTECTED] | �r himmlen s� f�runderligt bl�
> http://goethe.ira.uka.de/~wilhelmi |
>
> --
> To unsubscribe: mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
>
>
--
To unsubscribe: mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
