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

Hi Noel,

> 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?

Ok, could you please file a bug then with a minimal example showing that. The
GTK+ developers really are overloaded with work and need this help. Without a
bug report the chances are bad, that this will be fixed.

As for your other reply:
> 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.

Ok, I agree, that we might want to do that on a "You get, what you pay for"
base. I'll have a look into making that pluggable. However note, that as GLib
provides a portable thread code, we can't simply use pthread_self, but
g_thread_self(), which isn't currently found in glib-1.2.*, but will be in
Version 1.4.

> 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?

Actually I seldom program GUIs. I'm more into low-level stuff. But I really
think, that it shouldn't be hard to know, what functions hold the lock, and
which don't. To make it obvious, just write it above every function, whether
it holds the lock or not (We are doing it that way in GLib). Then
GTK+-functions must be called holding the lock. GTK+ callbacks hold the lock,
Other Callbacks don't. 

Sure, it is a burden. I'll have a look. There might be an alternative for 1.4.

Sebastian Wilhelmi                   |            här ovanför alla molnen           |     är himmlen så förunderligt blå   |

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