Re: Moving to pointer-sized GType? (fwd)

[Tim Janik <timj gtk org>]

continuing the saga ;)

---
ciaoTJ

---------- Forwarded message ----------
Date: Tue, 18 Sep 2001 17:54:02 +0200 (CEST)
From: Tim Janik <timj gtk org>
To: Dan Winship <danw ximian com>
Cc: Alex Larsson <alexl redhat com>, Hacking Gnomes <gnome-hackers gnome org>,
     GNOME MList <gnome-list gnome org>
Subject: Re: Moving to pointer-sized GType?

On 14 Sep 2001, Dan Winship wrote:

> > The change will be fully source compatible for code that correctly uses 
> > GType, but unfortunately there are some places in our codebases that use 
> > uint instead of GType/GtkType to store/handle types, and these will break 
> > on 64bit architectures (warning + segfault), but silently work on 32bit 
> > architectures.
> 
> Adding more ways for the teeming 32bit-only hordes to unwittingly break
> things for 64bit architectures seems bad. Couldn't you just make GType

right, that is my main concern with alex approach to go to pointer sized
GType. others are:
- g_type_parent(r=rand()) will not just puke on you (actually it's currently
  silent, but _should_ puke), but plain segfault if r is assumed to be
  castable into a valid pointer.
- g_type_name(rand()) _must_ continue to work, as that's the recommended
  way to figure whether a type id is at all valid (it just returns NULL
  silently, for invalid type ids). so for this, we'll have to do an extra
  lock and keep track of valid pointers to figure invalid things passed in.

the benefits however are large, we get rid of mostly all locks currently
aquired for invastigative type system functions, such as type_parent(),
check_instance, check_value, etc...
this lessens lock contention by a great amount which is pretty important,
as profiles so far have shown that a huge amount of time in 2.0 gtk
programs is spent in maintening rw locks from gtype.c functions.

> be a gpointer and use GPOINTER_TO_UINT or whatever in the few places
> where you want to think of them as integers? (Which would only be inside
> the type system itself, right?)

unfortunately this is not the case, this would affect any code that
currently does:

switch (G_TYPE_FUNDAMENTAL (foo->type)) {
  case G_TYPE_STRING: /*...*/ break;
  case G_TYPE_INT:    /*...*/ break;
  [...]
}

and then, there's the issue of
  pointer!=GUINT_TO_POINTER(GPOINTER_TO_UIN(pointer))
on some systems.

so, while we're well aware of sizeof(GType)=>sizeof(void*) breaking things
on some 64bit platforms, the current performance situation strongly suggests
that we'd want to do this (basically, because there's no lock-free way to
perform lookups from integer=>pointer, if the set of (integer,pointer) pairs
changes (for gtype.c: just grows) at runtime). considering that the type system
changes from 1.2 to 2.0 are huge enough that people will want to/have to pay
attention to Changes-2.0.txt anyways, putting an extra note there about
sizeof(int)==sizeof(GType) breaking from now on, should cause people to fix
most code that relies on this.

> 
> -- Dan
> 

---
ciaoTJ


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers