Re: [gtk-list] Re: gdk_threads_enter is not reentrant
- From: Noel Burton-Krahn <noel burton-krahn com>
- To: gtk-list redhat com
- CC: gtk-list redhat com, recipient list not shown: ;
- Subject: Re: [gtk-list] Re: gdk_threads_enter is not reentrant
- Date: 8 Mar 2000 23:43:34 -0000
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]