Re: struggling with the non-recursive gdk_threads_enter

[Nikolaj Thygesen <mailinglist diamondbox dk>]

Alexander Larsson wrote:
> On Tue, 2008-12-30 at 21:47 -0500, Yu Feng wrote:
>   
> > Dear Devels:
> >
> > I am having troubles because the GMutex used gdk_threads_enter/leave can
> > be non-recursive.
> >
> >     
> IMHO that is a Gtk+ bug. When loading the modules from GTK_MODULE it
> should take the Gdk lock in order to provide the same behaviour in both
> cases. The way its currently set up means its impossible to get module
> loadind gdk-thread-safe in all cases. 
>
>   
... and IMHO the whole locking scheme of gtk is flawed. The future 
belongs to multi-cores, so we must expect multi-threading to become a 
much more popular thing. What I did to work around the issue, was add a 
couple of lines like:

pthread_mutexattr_t gdk_lock_attr;
pthread_mutexattr_init(&gdk_lock_attr);
pthread_mutexattr_settype(&gdk_lock_attr, PTHREAD_MUTEX_RECURSIVE);
pthread_mutex_init(&gdk_lock, &gdk_lock_attr);
pthread_mutexattr_destroy(&gdk_lock_attr);
gdk_threads_set_lock_functions(lock_gdk_lock, lock_gdk_release);


but please be aware that some high-level gtk calls (dialogs), will 
expect to implicitly be able to unlock with a single call, and this must 
be handled in lock_gdk_lock() and lock_gdk_release() otherwise your app 
will hang.
Now I know that some will argue that using all these cumbersome 
"add_whatever_handler()", will make for much cleaner code and such, but 
that just isn't good enough IMO - it makes cluttered code. I agree that 
many scenarios are best handled by a model/view/ctrl setup, but 
different people have different styles, and an elitist "there's only one 
right way to do it" is too black and white.

br Nikolaj