Re: struggling with the non-recursive gdk_threads_enter

[Yu Feng <rainwoodman gmail com>]

Hi Friends,

Thanks for the hint.
I don't have the luxury to override the gdk locking functions since I am
writing a plugin module for arbitrary applications; the application may
also want to override the locking functions.

This is the solution I came up with:

in gtk_module_init, I defer the library init with a GIdle callback at
G_PRIORITY_HIGH. 

Then I am able to use GDK_THREADS_ENTER/GDK_THREADS_LEAVE to protect my
code, since the GIdle callback is invoked by the main loop, where the
gdk mutex is released.

This means when the library is initialized the state of the application
differs from when the module is actually loaded. But it works for my
module since the init code doesn't depend on the state of the
application.

Regards,

Yu
On Sun, 2009-01-04 at 13:30 +0100, Nikolaj Thygesen wrote:
> 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