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
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
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
* 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
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
Ensure callers get a warning if they pass a bad length.
Split into a separate commit and changed to order index before
n_children by Colin Walters <walters@verbum.org>
The previous implementation was buggy and wrote junk into config.h.
While we're at it, close bug #631231 by including syscall.h from the
correct location and using __NR_futex instead of SYS_futex.
There are some bugs caused by the way that gsettings-tool currently
attempts to help the user when they leave the quotes off of a string
value that they are setting.
Simplify the code to make it more robust and add some comments about why
it should be done this way.
https://bugzilla.gnome.org/show_bug.cgi?id=649915
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.
When loading a keyfile the incoming bytes are fed
to a line buffer to get parsed each time a new line
is encountered.
The code that fills the line buffer does it inefficiently,
one byte at a time.
This commit changes that code to look ahead at the incoming
bytes for the next '\n' character and then fill the line buffer
all at once.
https://bugzilla.gnome.org/show_bug.cgi?id=650211
When loading a key file, the keys and values of individual lines
are allocated once when copied and trimmed from the parse buffer
and allocated/copied again when added to the lookup map.
This commit avoids the second pair of allocations by introducing
a new function g_key_file_add_key_value_pair that gives the
lookup map direct ownership of the key and value copied from the
parse buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=650211
g_variant_new_string() hits a g_return_if_fail() when given invalid
UTF-8. That's certainly the right thing to do, but
g_variant_builder_add() uses this function internally and crashes when
it returns NULL due to the user passing a non-utf8 string.
We can protect the internal code by returning "[Invalid UTF-8]" in this
case while also making the problem easier to debug (and less fatal).
Closes#632631.
