Re: instance-private-data issue

[Owen Taylor <otaylor redhat com>]

On Wed, 2003-08-06 at 06:04, Michael Meeks wrote:

> On Tue, 2003-08-05 at 14:58, Owen Taylor wrote:

> > Hmm, that does provide an idea of a 4-bytes-per-GObject solution 
> > instead of a 8-bytes-per-GTypeInstance solution, as long as we are
> > willing to replace the public g_type_instance_get_private() with
> > g_object_get_private().
> > 
> >  A) Move GObject->qdata to the private data block and replace it
> >     with a ->priv pointer.
> >  B) Initialize that priv pointer using the second parameter to
> >     g_object_init()
> 
> 	Well; right - but I guess that breaks API/ABI in theory - although I've
> never seen code that actually fishes at object->qdata;

object->qdata is documented as private in the header; while people
*do* access private fields on occasion, and we try not to break
things like accessing button->event_window, I really
can't imagine that anybody accessed object->qdata or, if they
did, thought that that was a legal operation. 

>  I'm assuming that
> by construction time you have all the per-class private struct sizes -
> since they've all been setup in the class_init ? - so that we can
> allocate the private in the same chunk as the GObject if we're clever ?

Yes, allocating the chunk all works nicely now. The trouble is
finding it...

> 	It's nice that GData is a fully private structure, so no layout is
> implied; so there are several interesting solutions; perhaps the lowest
> cost, and most evil one ;-> is this:
> 
> 	->qdata points to the first byte of the extended post-GObject alloc'd
> section [ gpointer *extended; ]
> 	*extended points to either an allocated GData * or NULL - but the
> pointer has the lowest bit set ;-)
> 	*(extended + 1 + [double pad]) points to the first private section.
> 
> 	Of course - then all the GData methods would need to check for the flag
> on the pointer; unmask it and de-reference again, but it is then fully
> ABI compatible.

I don't think anything that evil is needed, luckily. (If you
did need to do it, GData isn't quite object like you are 
thinking - it is used as:

  g_datalist_init (&object->qdata);

so the scheme would be twisted in a slightly different direction.)

> 	;-) of course - you're going to need to do the double alignment stuff
> anyway in the offset / size calculations, which is quite fun - but
> there's working code in ORBit2 that does all that.

We've already considered the alignment issues to manage having the
private data in the aloocated same block at all.

[....]

> > 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.

Regards,
						Owen