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