Re: instance-private-data issue

[Michael Meeks <michael ximian com>]

Hi Owen,

On Tue, 2003-08-05 at 14:58, Owen Taylor wrote:
> You probably missed the suggested hack; the extra fields go *before*
> the beginning of the type-instance struct. That is, the same hack
> that ORBit uses for storing CORBA_free information.

	Ah - sorry; that seems reasonable enough I suppose - of course - there
are some fun things to be said wrt. alignment & doubles on some
architectures - but they're doable.

> Yes, we have that in place. It's not just a question of effiency; it's
> also about being able to add private data to existing widgets.

	Ah - nice; I see - this is a really cool feature.

> > 	Presumably; in a singly inherited world - if you resigned yourself to 2
> > allocations per object - they could be sanely blocked off into a single
> > separate allocated block 
> 
> Where do you store a pointer to this separately allocated block? If you
> have a place to store that, you might as well store a pointer to the
> private data part of the main allocation.

	Hrm; well - I suppose so.

> 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; 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 ?

	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.

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

> Well, with that scheme, you could potentially do:
> 
> #define MY_A_GET_PRIVATE((MyA *)((guchar *)G_OBJECT(a)->priv + private_offset_var))
> 
> and have a no-function-call solution. But that makes the interfaces
> a messier.

	sure - but it's best not to expose that sort of API of course.

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

	Interesting anyway; and evil hacks aside this is a great implementation
thing that I'm looking forward to seeing in real use, great work.

	Regards,

		Michael.

-- 
 michael ximian com  <><, Pseudo Engineer, itinerant idiot