Don't bail out if a directory suddenly turns out to exist after all. Proposed in bug 612729.
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
These are actually byte arrays.
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
Not really necessary to double-check the ref-count.
Not really necessary to constantly double-check the ref count, anyway.
g_socket_shutdown and g_socket_close were calling check_socket with a NULL error parameter so any errors wouldn't get propagated up. https://bugzilla.gnome.org/show_bug.cgi?id=651327
The GError message for g_socket_shutdown was reporting that it was "Unable to create socket" which is presumably a cut-and-paste bug. https://bugzilla.gnome.org/show_bug.cgi?id=651327
…locks * 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
…as a copy 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
Move @key to not be at the start of a line, otherwise g-ir-scanner gets confused. Also two annotation fixes.
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 <firstname.lastname@example.org>
We don't ref the returned object, and alex has verified the gvfs implementation.