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:
> 
> > i'd really say then they make the wrong assumptions and didn't get how
> > to do threaded programming in glib. what point is there in just reffing
> > objects in threads? at some point they're going to use it and then they
> > need some global object-entity lock anyways.
> 
> I agree with the rest of your mail, but I'm not sure about this.
> 
> 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.

> 
> Anyway. Too late.

not really, thread safe ref-counting could still be added in 2.2 binary
compatible. well, granted there could be minor source incompats, but since
the ref_count is said to be private already, we could still change it's
definition to struct { volatile guint ref_count } private; right now
if we wanted to.

> 
> / Alex
> 

---
ciaoTJ