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

[Stefan Kost <ensonic hora-obscura de>]

hi again,

this with the thread was a bad idea ;).
I now have a solution that is imho hacky.
I wrap my g_object_set() call by gdk_threads_leave()/enter() to 
temporaily release the lock.

Meanwhile I have downloaded the sources of a lot of gnome apps and now I 
will study how they do it.

Thanks a lot for your help so far. Still the gdk_threads_leave()/enter() 
has to happen in my gtk app and can't happen in the core-lib.
The core lib does not even depend on gdk.

Stefan

> 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
> >  
>
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list