Re: instance-private-data issue

[Michael Meeks <michael ximian com>]

Hi Owen,

On Sun, 2003-08-03 at 01:08, Owen Taylor wrote:
> So, how do we fix the problem? Two ideas I can come up with:
> 
>  - increase GTypeInstance from 4 bytes to 8 bytes (on
>    32 bits), caching the real type *before* the public g_class field.

	Presumably; (and this is just a stab in the dark) changing the size of
GTypeInstance from 4 to 8 bytes (16 on 64bit machines) would also offset
all derived GObject's fields:

struct  _GObject
{
  GTypeInstance g_type_instance;

  guint         ref_count;
  GData        *qdata;
}

	and break binary compatibility of most gtk+ / Gnome applications ? or
am I mis-understanding things / is this some deep future design thing ?

	From what I remember of grubbing in class_init's there was some way to
get the true class of the type being initialized which came in some 2nd
argument to the _class_init that most people never used; could that not
also be used in this instance ? in combination with a
g_type_instance_toolong_get_private_from_class (real_class, MY_TYPE_A,
MyA); ?

	Or is that going to be too complex for people to remember ? I'm
assuming randomly having not looked (sorry) that this is all part of a
cunning plan to make people's separately allocated ->priv pointers more
efficient by block allocating them after the object instance ?

	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 [ you could I guess even put the GData struct
at the top of that, and re-use that pointer ? ;-) ]

	That would have the advantage of the offsets being invariant across
objects of the same type, and evaluating to a constant offset for that
type, potentially removing the need for more complexity ?

>  - Use thread-private data to keep track of a stack of
>    currently-being-initialized objects with their real types, and 
>    have g_type_instance_get_private() check that.

	I didn't understand the problem B) with using __thread variables in
glib:

 B) We can't use __thread variables in GLib, even #ifdef'ed
    because of g_thread_init (my_vtable); They do accelerate
    g_static_private_get() indirectly, through the chain
    of
       g_static_private_get => g_thread_self => g_private_get =>
       g_private_get_posix_impl() => pthread_getspecific ()

	HTH,

		Michael.

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