Re: gdk_threads_enter/leave() in threaded and non threaded situation

[Stefan Kost <ensonic hora-obscura de>]

Hi hi,

it is still not that simple :(

I have a core lib, that is used by a commandline and by a gtk based app. 
All is gobject based.
In the core lib I have an object A that has a property A.a.
Now from the gtk app I set this property from a thread (when playing) 
and from my main thread (via user interaction).
Other parts in the app subscribe to notify::A.a.
The property A.a can be changed via g_object_set, but also changes 
during an action (playing).
In the later case I call g_object_notify(G_OBJECT(self),"play-pos");

The g_object_set() is called from a signal callback that gets triggered 
by user action and thus already runs gdk_mutex protected.
Wrapping this with enter/leave would block.
I can wrap the g_object_notify() with the mutex instead, but that feels 
wrong, as this is an object in the lib, that can be accessed from 
non-gtk apps as well. In that case gdk_thread would not be initialized.

The main problem is that the docs are not clear where exactly one needs 
to put enter/leave call. And if the it is wrong in just one place that 
whole app can start to behave odd.

> On Thu, 10 Feb 2005 22:20:51 +0100, Stefan Kost <ensonic hora-obscura de> wrote:
>  
>
> > hi hi,
> >
> > I have a gobject property that is set (via g_object_set()) from within a
> > thread and from the main thread.
> > Further I have signal handlers that watch this via notify::property.
> > These signal handler call gtk functions. Therefore in these signal
> > handlers the gtk part is wrapped with gdk_threads_enter/leave().
> > When the singnal is triggered from the thread it works, but when it gets
> > triggerd from the main thread gdk_threads_enter blocks.
> >
> > This is quite obvious, as in this thread I am already in
> > gdk_threads_enter(). But how should the signal handler know that (wheter
> > it has been triggered from the main thread or from another thread)?
> >    
>
> Maybe you should protect g_object_set() with gdk_threads_mutex and
> assume that when you are in a signal callback, that you already have
> aquired the mutex (which should be the case for any signal emited by gtk+
> anyway).
>
> Cheers,
>                                                -Tristan
>