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

[Stefan Kost <ensonic hora-obscura de>]

another go in trying to make the situation clear.

I have two place in the source that is causing the notify signal to be 
emited:
A) core lib :: sequence.play()
   * when called from a gtk app it will run inside a thread
   * the method directly changes the property and calls g_object_notify()
B) gtk app :: sequence-view.button_press()
   * is already protected by enter()/leave()
   * uses g_object_set() to change the property in the core lib

The consumer of the notify:: signal is in the gtk app and call gtk methods.
When A) sent the notify it would need to protect the gtk-calls by 
enter()/leave().
If B) has triggered the notify if must not, as this blocks.

Pushing the enter()/leave() upstream is not easy as well.
A) can't use enter()/leave() as it is not gtk related and b) can't as 
this would block.

The only idea I now have is when starting the thread from the gtk-app, 
not starting sequence.play() as a thread.
Instead creating a method in the gtk app that is started as a thread and 
that calls sequence.play() wrapped by enter()/leave().

I'll try this now.

Stefan

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