Also use dist-bzip2.
See https://bugs.freedesktop.org/show_bug.cgi?id=37890#c6 where it was discovered that dbus-send(1) actually doesn't work (either libdbus-1's flush implementation or dbus-send(1)'s usage of it is broken) so it's useful to have here. Signed-off-by: David Zeuthen <email@example.com>
Don't bail out if a directory suddenly turns out to exist after all. Proposed in bug 612729.
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 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.  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49244 https://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
This avoids the generated types (e.g. ExampleAnimal, ExampleCat, ExampleObject and ExampleObjectManagerClient) being referenced in the core gio docs. This was requested by Matthias. Signed-off-by: David Zeuthen <firstname.lastname@example.org>
…ublic headers This helps out gtk-doc and g-ir-scanner, and also makes much clearer what's private versus public. https://bugzilla.gnome.org/show_bug.cgi?id=651745