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
I can't see a reason to spin until the worker thread runs, so don't.
This avoids ugly sched_yield() calls that show up in strace and
annoy me; the code is cleaner now too.
We now grab the types needed for the WebKit workaround in the
thread creation area, but only release them when the thread itself
exits.
https://bugzilla.gnome.org/show_bug.cgi?id=651650
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
In resolve_sync function in gthreadedresolver.c, if g_thread_pool_push
fails due to thread creation failure, we are just simply appending the
data to the queue of work to do. After the failure, we might wait
indefinitely in g_cond_wait. In case of g_thread_pool_push failure,
propagate the error so that this function does not blocks forever in
case of failure.
https://bugzilla.gnome.org/show_bug.cgi?id=651034
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 22e7fc34c4 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
The fact that we return 0 here makes it clear that this
is not considered an error, so it makes sense to not
write these messages to stderr.
Proposed by Antoine Jacoutot,
https://bugzilla.gnome.org/show_bug.cgi?id=650882
