Re: instance-private-data issue

[Owen Taylor <otaylor redhat com>]

On Wed, 2003-08-06 at 12:12, Tim Janik wrote:
> 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.)

Allowing for user space threads was the reason why we provided the
ability to pass in a vtable to begin with. The cuser space threads
that guile was using at that point was a particular concern, as
a recall.

So, yes, that's whawt I was thinking of.

Regards,
						Owen