Re: instance-private-data issue

[Tim Janik <timj gtk org>]

On 6 Aug 2003, Owen Taylor wrote:

> Hmm, so your plan is essentially (suppressing storing the
> classes for each object for simplicity):
>
>  G_LOCK_DEFINE_STATIC (initializing_instances);

[...]

> (The initializing_instances_empty variable is actually superfluous, but
> would be needed if you were using an array.)
>
> and the claim is that:
>
>  * If there are any objects being initialized in this thread, then
>    this thread must see initializing_instances_empty as TRUE, since
>
>    *) After add_initializing_instance, it will be seen as TRUE
>       by this thread
>    *) No thread can set it FALSE until after this thread calls
>       remove_initializing_instance on the object
>
> Yeah, I think that does work. It's not as quite as good as
> ultra-fast thread-private-data (__thread) because it's certainly
> possible to have an object that in its init does something slow
> (reads in a big file fom disk, say), but probably good enough.
>
> Regards,
> 					Owen
>
> [
>   Does it make sense to use a separate lock rather than the
>   global gtype reader-writer lock? I think it might, since
>   avoiding write-locks when not actually modifying the type
>   data is a good thing.
> ]

ok, so you're arguing in favour of a seperate (static) lock for
this. is this also arguing in favour of using a normal static lock
vs. a static read-write lock? (note that we at least don't need
to use a static lock if we forgo the rw-feature)

---
ciaoTJ