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
This adds the two new functions g_type_add_class_private()
and g_type_class_get_private() and a convenience macro
for the getter G_TYPE_CLASS_GET_PRIVATE().
This way we don't need to keep a custom array that we bsearch on (and
that isn't threadsafe) but can use the gtype.c machinery that is
threadsafe. And fast, too!
https://bugzilla.gnome.org/show_bug.cgi?id=554887
g_type_default_interface_peek() and g_type_value_table_peek() don't need
to acquire read locks anymore when they test the refcount instead of
node->data.
The function returns TRUE if the type was previously initialized and can
be easily reused. It returns FALSE and does not take a reference if the
type is not referenced yet.
g_type_class_ref() uses this to avoid taking locks in the common path,
which speeds up object creation a lot - in particular in multithreaded
applications.
https://bugzilla.gnome.org/show_bug.cgi?id=585375
This does not change any locking behavior at all, it just replaces
simple getters/setters of the variable with atomic versions.
The ref_count variable was kept as unsigned, even though that requires
casting for all operations, to mirror GObject->refcount.
https://bugzilla.gnome.org/show_bug.cgi?id=585375
Currently interface lookups are do a binary search over all the interfaces
an object implements. Its possible to do this lookup in constant time using for
instance the gcj algorighm described at:
http://gcc.gnu.org/ml/java/1999-q3/msg00377.html
This is an implementation of that based on GAtomicArray.
We implement lock free interface lookup by moving the n_ifaces
counter into memory pointed to by TypeNode->iface_entries, and
then updating this in RCU-style by always copying it, modifying
the copy and then when the modification is done replace the old
pointer with g_atomic_pointer_set.
There is one additional complexity when freeing the old memory,
since the old memory region can be in use. To handle this we
don't free such memory, but put it on a free list and reuse it
later. This means that lock-free lookups must be able to
handle the memory being modified in random ways without crashing,
and at the end we verify that the memory didn't change and the
transaction is ok.
With this infrastructure the patch then implements a lock-free
version of type_lookup_iface_entry_L called type_lookup_iface_vtable_I
and use it in: g_type_interface_peek, g_type_interface_peek_parent
and type_node_check_conformities_UorL.
Using the performance tests from bug 557100 shows that the general
performance difference is negligible, but the lack of a lock for each
type check and interface vfunc call should greatly enhance threaded
scalability.
The n_children variable can be written when locked, while the n_supers
variable is read at any time. As they both share the same bytes,
accessing them is not threadsafe.
This patch puts them into different bytes.
Thanks to Xan Lopez and valgrind for noticing this.
