Re: GObject thread safety

[Tim Janik <timj gtk org>]

On Sat, 3 Nov 2001, Alex Larsson wrote:

> On Sat, 3 Nov 2001, Tim Janik wrote:
> 
> > On Sat, 3 Nov 2001, Alex Larsson wrote:
> 
> > > If I implement a class (even a class hierarchy), deriving from GObject, 
> > > and I've taken my time to make the classes internally thread safe (say 
> > > it's a process wide data object). I'm not using signals or object data, 
> > > and all the class methods are thread safe. Now I can use this object in 
> > > several threads. Except I can't memory manage it threadsafely, without 
> > > having my own ref/unref wrappers.
> > 
> > i wonder what you want to gain from a data object that can't emit
> > notification e.g. when it's data changes. without signals and object data,
> > i'd be interested to hear why this is an object at all.
>  
> Yeah. It's sort of silly, but it could at least use the typesystem.

if that's the only point, you probably want to implement your own
base object type ;)
that, in conjunction with special closures you setup which operate
on a recursive mutex, could even be thread safe for signal emissions.
(with special closures i mean adding guards that not only reference
the object as is done for GObject, but also lock/unlock a recursive
mutex). of course, you'd go to deadlock with
  connect_object (A, "sig", func, B);
  connect_object (B, "sig", func, A);
thread1: emit (A, "sig");
thread2: emit (B, "sig");

but without the second emission, instead doing:
thread2: do { lock(B); ping(B); unlock(B); } while (!done);

this'd make a cool testprogram ;)

> 
> / Alex
> 

---
ciaoTJ