g_queue_remove() should return a boolean so callers can verify that an
element was found and removed, as in the following example:
if (g_queue_remove (queue, referenced_object))
g_object_unref (referenced_object);
Similarly, g_queue_remove_all() should return the number of elements
found and removed.
https://bugzilla.gnome.org/show_bug.cgi?id=632294
When getting the mutex implementation of a static mutex, avoid taking the global
lock every time but only take the lock when there was no mutex and we need to
create one.
https://bugzilla.gnome.org/show_bug.cgi?id=599954
Instead of converting the string to a quark and comparing quarks we
use the new lockless g_quark_to_string and just compare the quarks
in the datalist with the given string.
This means we avoid the global lock for string to quark. Additionally
most of the time the data list will be quite short, so the cost of
doing the sting comparisons is likely similar to that of the quark
hashtable lookup (which does at least one string comparison for a
successfull lookup).
https://bugzilla.gnome.org/show_bug.cgi?id=650458
We do this by assigning to g_quarks atomically and leaking it when
replacing it atomically. Then its safe to consume the array
on the reader side (atomically).
Also, since we're leaking quarks on growing, bump the block size
so that we're not leaking as much. gtk3-demo allocates > 1500 quarks,
and gnome apps > 3000. I'm setting the block to 2048 which means no
leaks for small gtk3 apps and just one leak for gnome apps.
https://bugzilla.gnome.org/show_bug.cgi?id=650458
This implementation uses a per-list bitlock for user data, and a
simple array rather than a linked list which uses less memory and less
allocations. It also gets better cache behaviour since related things
are stored close to each other.
https://bugzilla.gnome.org/show_bug.cgi?id=650458
The __sync_fetch_and_or() operation on x86 is a bit suboptimal when the
result isn't ignored. Normally we could use the 'lock or' assembly
instruction to accomplish this, but this instruction discards the
previous value.
In order to work around this issue, GCC is forced to emit a
compare-and-exchange loop.
We can easily use the 'lock bts' instruction, though. It can't be used
in the general case for __sync_fetch_and_or() but it works great for our
case (test and set a single bit).
I filed a bug against GCC[1] to get this exposed as a new intrinsic (or
have the optimiser detect the case) but until then we'll hand-code it on
x86 and amd64.
The uncontended case sees a 31% improvement on my test machine.
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49244https://bugzilla.gnome.org/show_bug.cgi?id=651467
g_variant_get_strv and g_variant_get_bytestring return arrays that
are null terminated and have an explicit length. Since gjs doesn't
support (out) arrays with length, mark them also null-terminated
(but leave the length annotation, so pygobject can remove the argument)
https://bugzilla.gnome.org/show_bug.cgi?id=646635
Unify it more with the rest of the signal handling code. There's
no reason not to specify SA_RESTART and SA_NOCLDSTOP for flags
always, so just do it.
Remove unnecessary initialization, and push the internal API
towards just ensure_unix_signal_handler_installed_unlocked().
https://bugzilla.gnome.org/show_bug.cgi?id=651725
Based on a patch by Giovanni Campagna <gcampagna@src.gnome.org>
From discussion, GVariantIter is not useful for bindings, but
GVariantBuilder may be.
https://bugzilla.gnome.org/show_bug.cgi?id=646635
Add a performance test for bitlocks.
Make use of the new g_atomic_int_{and,or} to avoid having to do the
usual compare-and-exchange loop.
On a test machine, the change increases performance from approximately
20 million uncontended acquire/releases per second to 31 million.
Commit 22e7fc34c44c5ef95abf4fed429f2345410cc82c introduced a regression:
futexes were always disabled and the emulated codepath was always being
used. That commit was in response to an originally buggy
implementationt hat wrote junk into config.h (but happened to be working
properly).
Fix up the mess and while we're at it, close bug #631231 by including
syscall.h from the correct location and using __NR_futex instead of
SYS_futex.
Closes#631231.
- remove all inline assembly versions
- implement the atomic operations using either GCC intrinsics, the
Windows interlocked API or a mutex-based fallback
- drop gatomic-gcc.c since these are now defined in the header file.
Adjust Makefile.am accordingly.
- expand the set of operations: support 'get', 'set', 'compare and
exchange', 'add', 'or', and 'xor' for both integers and pointers
- deprecate g_atomic_int_exchange_and_add since g_atomic_int_add (as
with all the new arithmetic operations) now returns the prior value
- unify the use of macros: all functions are now wrapped in macros that
perform the proper casts and checks
- remove G_GNUC_MAY_ALIAS use; it was never required for the integer
operations (since casting between pointers that only vary in
signedness of the target is explicitly permitted) and we avoid the
need for the pointer operations by using simple 'void *' instead of
'gpointer *' (which caused the 'type-punned pointer' warning)
- provide function implementations of g_atomic_int_inc and
g_atomic_int_dec_and_test: these were strictly macros before
- improve the documentation to make it very clear exactly which types
of pointers these operations may be used with
- remove a few uses of the now-deprecated g_atomic_int_exchange_and_add
- drop initialisation of gatomic from gthread (by using a GStaticMutex
instead of a GMutex)
- update glib.symbols and documentation sections files
Closes#650823 and #650935
* g_static_private_get: have a single entry and exit
* g_static_private_set: delay creation of GArray so the whole tail of
the function can be under the private_data lock without risking
deadlock with the g_thread lock; call the destructor last, after
we could have unlocked
* g_static_private_free: choose next thread in list before accessing
private_data, to keep all accesses together
* g_thread_cleanup: steal private_data first, then work exclusively with
the stolen array (which doesn't need to be under a lock any more)
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=642026
Bug-NB: NB#257512
Make sure that the macros work properly with the range of types that
they are documented to work with and ensure that no strict aliasing
warnings are issued (even at the highest warning level).
https://bugzilla.gnome.org/show_bug.cgi?id=650935
