Moving to pointer-sized GType?
- 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?
- Date: Fri, 14 Sep 2001 12:08:48 -0400 (EDT)
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
Most of the bugs are of the type:
static guint mw_type = 0;
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?
] [Thread Prev