This reverts commit ddb0ce1421.
Colin's smoke testing has found issues in at least gjs and
gnome-settings-daemon. We'll need to see if we can address those.
GObject has previously allowed installing properties after class_init
has finished running. This means that you could install some of your
own properties on G_TYPE_OBJECT, for example, although they wouldn't
have worked properly.
Prevent this from happening. Require that all properties are installed by
the time class_init has finished.
Complaints go to this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=698614
Classically, a GTypeInstance has had the following layout:
[[[[GTypeInstance] GObject] TypeA] TypeB] [TypeAPrivate] [TypeBPrivate]
where TypeB is a subclass of TypeA which is a GObject. Both TypeA and
TypeB use pivate data.
The main problem with this approach is that the offset between a pointer
to an instance of TypeA and the TypeAPrivate is not constant: it changes
depending on the depth of derivation and the size of the instance
structures of the derived types. For example, changing the size of the
TypeB structure in the above example would push the TypeAPrivate further
along.
This complicates the implementation of g_type_instance_get_private().
In particular, during object construction when the class pointer to the
'complete type' of the object is not yet stored in the header of the
GTypeInstance, we need a lookup table in order to be able to implement
g_type_instance_get_private() accurately.
We can avoid this problem by storing the private data before the
structures, in reverse order, like so:
[TypeBPrivate] [TypeAPrivate] [[[[GTypeInstance] GObject] TypeA] TypeB]
Now the distance between TypeA and TypeAPrivate depends only on the size
of GObject and GTypeInstance, which are static. Even in the case of
TypeB, the distance is not statically known but can be determined at
runtime and is constant (because we will know the size of TypeAPrivate
by the time we initialise TypeB and it won't change).
This approach requires a slighty dirty trick: allocating extra memory
_before_ the pointer we return from g_type_create_instance(). The main
problem with this is that it will cause valgrind to behave very badly,
reporting almost everything as "possibly lost".
We can correct for this by including a few valgrind client requests in
order to inform it that the start of the GTypeInstance should be
considered a block of memory and that pointers to it should mean that
this block is reachable. In order to make the private data reachable,
we also declare it as a block and include an extra pointer from the end
of the primary block pointing back at it. All of this is only done if
we are running under Valgrind.
https://bugzilla.gnome.org/show_bug.cgi?id=698595
gtk# also has a problem with the new interface-after-init restriction
that nobody noticed until now. Add an exception for them as well so
that they have a cycle or so to sort things out.
https://bugzilla.gnome.org/show_bug.cgi?id=687659
glibmm has a pretty difficult-to-solve problem caused by our recent
change to deny addition of interfaces to classes after initialisation.
They're looking for a long-term workaround for the problem, but in the
meantime we can allow the registration to succeed (with warning) if the
class looks like it's being defined by gtkmm.
https://bugzilla.gnome.org/show_bug.cgi?id=697229
Experimentally disable the ability to unload dynamic types by refusing
to drop the last reference on types (effectively turning the type
unloading into dead code).
The plan is to leave things like this for a stable cycle and only
proceed with removing the code if we are sure that there are no
unforeseen problems.
https://bugzilla.gnome.org/show_bug.cgi?id=693351
Add a check to prevent adding an interface to a class that has already
had its class_init done.
This is an incompatible change but it is suspected that there are not
many users of this functionality. Two known exceptions are pygobject
(fixed in bug 686149) and our own testsuite (affected tests have been
temporarily disabled by this patch).
Once we confirm that nobody else is using this functionality we can
remove a rather large amount of code for dealing with this case.
https://bugzilla.gnome.org/show_bug.cgi?id=687659
Add a check to prevent adding an interface to a class that has already
had its class_init done.
This is an incompatible change but it is suspected that there are not
many users of this functionality. Two known exceptions are pygobject
(fixed in bug 686149) and our own testsuite (affected tests have been
temporarily disabled by this patch).
Once we confirm that nobody else is using this functionality we can
remove a rather large amount of code for dealing with this case.
https://bugzilla.gnome.org/show_bug.cgi?id=687659
When g_type_class_get_private is called without calling
g_type_add_class_private first, a g_warning is issued, but
the name of the function to call is wrong:
g_type_class_add_class_private.
https://bugzilla.gnome.org/show_bug.cgi?id=690348
This lets you cache type lookup information and then know when
the cache information is out of date. In particular, we want this
in order to be able to cache g_type_from_name() lookups in the Gtk+
theme machinery.
https://bugzilla.gnome.org/show_bug.cgi?id=689847
Add a check to prevent adding an interface to a class that has already
had its class_init done.
This is an incompatible change but it is suspected that there are not
many users of this functionality. Two known exceptions are pygobject
(fixed in bug 686149) and our own testsuite (affected tests have been
temporarily disabled by this patch).
Once we confirm that nobody else is using this functionality we can
remove a rather large amount of code for dealing with this case.
https://bugzilla.gnome.org/show_bug.cgi?id=687659
Move the guts of g_type_init() into a ctor and turn g_type_init() itself
into a do-nothing function.
g_type_init_with_debug_flags() now ignores its arguments, but it has
always been possible to achieve the same effect via environment
variables.
https://bugzilla.gnome.org/show_bug.cgi?id=686161
Otherwise we crash with a null-ptr deref in g_object_newv and ever there we
should not return null, as we're saying that object creation will not return
null.
It's impossible to check this if the library user is using
g_type_register_static, but in that case their compiler should hopefully
warn about the truncation. This fixes it for G_DEFINE_TYPE and friends,
at least.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=659916
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
All locks are now zero-initialised, so we can drop the G_*_INIT macros
for them.
Adjust various users around GLib accordingly and change the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=659866
G_THREADS_ENABLED still exists, but is always defined. It is still
possible to use libglib without threads, but gobject (and everything
above it) is now guaranteed to be using threads (as, in fact, it was
before, since it was accidentally impossible to compile with
--disable-threads).
https://bugzilla.gnome.org/show_bug.cgi?id=616754
Some links were broken due to typos, because functionality was removed
in GLib 2.0 or for various other reasons. Fix up as many of them as is
reasonable.
The hash table used exclusively for looking up types by name used to map
quarks => types. But we can easily make it map strings => types, which
avoids the quark lookup. And that in trun avoids taking a lock and
consulting another hash table. So this change should make
g_type_from_name() roughly twice as fast.
This adds static markers and systemtap tapsets for:
* type creation
* object lifetimes (creation, ref, unref, dispose, finalize)
* signal creation and emission
Signal emissions and finalization marker have a corresponding
*_end (or *-end in dtrace) version that is when the corresponding
operation is finished.
https://bugzilla.gnome.org/show_bug.cgi?id=606044
