Re: instance-private-data issue

[Tim Janik <timj gtk org>]

On 6 Aug 2003, Owen Taylor wrote:

> > > The problem here is that someone could use the argument to g_type_init()
> > > to replace the standard GLib threading with a user-space implementation
> >
> > 	Doh - that sucks.
> >
> > > where __thread variables don't work properly (because it all looks
> > > like one thread to the OS.) Such a situation is unlikely to work
> > > fully correctly, because GLib does depend on the C library being thread
> > > safe, but I'm not sure we can simply declare it non-working.
> >
> > 	Hmm; ;-) so one is reduced to having some nasty macro that uses either
> > a __thread variable or a g_private_slow (); dependant on whether
> > g_thread_init has been called with NULL or not ?
> >
> > 	Does anyone really need or use the g_thread_init (foo) stuff ?
>
> I doubt it, any more. I want to document it as deprecated in the docs,
> and *maybe* if we do that, we can get away ignoring the vtable parameter
> for GLib 2.6 or 2.8.

if it keeps us from using __thread, i'd be all for it.
i don't quite see yet, why exchanging glib threading functions
interferes with using __thread though, since the protections
and mechanisms to implement __thread are fully glibc contained.

or are you thinking about someone implementing user space threading
and expecting glib to cope with that? (in which case the same __thread
variable instance could be accessed from multiple user-space threads.)

>
> Regards,
> 						Owen
>

---
ciaoTJ