closure threading issues
- From: Tim Janik <timj gtk org>
- To: Owen Taylor <otaylor gtk org>, Havoc Pennington <hp redhat com>, Sebastian Wilhelmi <wilhelmi ira uka de>, Karl Nelson <kenelson ece ucdavis edu>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: closure threading issues
- Date: Mon, 29 Jan 2001 18:18:53 +0100 (CET)
hey owen, havoc, sebastian, kenelson,
with the recent addition of g_signal_newc() that internally creates
a closure, we can theoretically have objects that don't live under
a common global lock (like for instance Gtk ones) sharing a closure.
closures themselves provide no extra guarding code wrg thread safety,
and i'd rather leave it at that, since in general clashes here
shouldn't occour and locks would prolly just slow down things
(and the closure code is sufficiently complex already).
however, as mentioned above, that requires users to access objects
of the same class only from within a single common lock, and as
we move away from gtk/gdk objects, i'm not sure that requirement
holds true anymore.
we'll have to choose either of:
1) the user has to provide threading guards at least per-class
that he uses objects off (i think that will break at pure
G_TYPE_OBJECT level already)
2) users will definitely use objects of the same class from
different threads (that's what applies to G_TYPE_OBJECT already
though we could make that an ugly exception with some closure
i guess the outcome of this is (2) and that in turns requires proper
gclosure.c locking that i don't feel overly comfortable with.
usign one global closure lock is prone to cause a lot of runtime
collisions, hurting performance, while using per-closure locks
will considerably bloat memory.
] [Thread Prev