Moving to pointer-sized GType? (fwd)

[Tim Janik <timj gtk org>]

hum, just noted that alex forgot to put gtk-devel on the
Cc: list for this thread. this is basically the continuation
of "Re: Less locking in gtype.c", i.e. about whether we want
to pay the API breakage costs involved by such a change.
so if there are any comments from people just on this list and
not on gnome-hackers/gnome-list, speak up ;)

---
ciaoTJ

---------- Forwarded message ----------
Date: Fri, 14 Sep 2001 12:08:48 -0400 (EDT)
From: Alex Larsson <alexl redhat com>
To: gnome-hackers gnome org, gnome-list gnome org
Cc: timj gtk org
Subject: Moving to pointer-sized GType?

In GObject, the new Object system in Gtk+ 2, we are thinking of changing 
the GType type (replacement for GtkType) so that sizeof(GType) == 
sizeof(gpointer). GType is currently an uint which is 32 bit, so this 
change will affect all architectures where pointers are 64 bit.

The reason for this change is performance. When going from a 32bit GType 
to the data about the type we need to do a lookup in a data structure, 
and since this structure can change there has to be locks around it to be 
threadsafe. This unfortunately means that all type operations (including 
type-checks and type-checking casts) have locks in them.

Going to a pointer sized type lets us store the pointer in the GType, 
thereby giving a significant performance increase.

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.

Most of the bugs are of the type:
guint 
message_window_get_type (void)
{
  static guint mw_type = 0;

or:
GtkType
gimp_channel_list_view_get_type (void)
{
  static guint view_type = 0;

These can all be found by eliminating all appearances of guint in the 
output of 'find -name "*.c" | xargs grep -C2 _get_type', and we have done 
so for Gtk+, Gimp and gnome-libs. But the possiblility exists that some 
code stores GtkTypes in 32bit integers in some other fashion.

Doing this change will almost certainly cause some apps to segfault on 
64bit while working on 32bit until all our apps are fixed. 

We (the Gtk+ team) are interested in the opinion of developers (especially 
on 64bit systems) on this change. Do you think it is worth it? Do you know of any 
code that stores GtkTypes in uints currently?

/ Alex