closure threading issues

[Tim Janik <timj gtk org>]

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

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.

---
ciaoTJ