On Fri, 11 Feb 2005 19:06:44 +0100, Stefan Kost <[EMAIL PROTECTED]> wrote:
[...]
> 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.
gdk_threads_enter/leave do nothing if the gdk_thread_mutex is not
initialized or the code is compiled without GDK_THREADS_ENABLED,
actualy, gtk+ internals typicly make calls directly to the GDK_THREADS_ENTER/
LEAVE() macros because they expand to a no-op when compiled without
GDK_THREADS_ENABLED.
Again, I wouldn't sugest protecting g_object_notify(), because it is already
part of an object's code (i.e. you dont call g_object_notify on an object that
you've instantiated, only on the object that you are "writing").
The simple rule is this:
If you protect your object accesses with the mutex and keep all your
gdk_thread_enter/leave calls in the procedural code/buisiness logic
(and outside of your objects or signal callbacks), then you wont have
this problem.
OTOH, there may be an issue in your time-slices; it might be too
expensive to protect such a large non-critical area of code; if thats
the case, you'll have to keep all your possible use cases in mind and
handle them on a case per case basis or structure your code so that
its always obvious which objects are "owned" by which objects and
which of those are responsable for aquiring a lock when accessing
its delagates; in other words you have a lot of thinking to do if you
dont follow that simple rule.
Cheers,
-Tristan
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
