The choice between g_variant_iter_next() and g_variant_iter_loop() is a
bit confusing for some people. Add a note to the documentation of
g_variant_iter_loop() to clarify that it should be avoided except in a
few specific cases.
Add G_VARIANT_TYPE_OBJECT_PATH_ARRAY along with accessor functions
g_variant_new_objv, g_variant_get_objv and g_variant_dup_objv. Also add
support for '^ao' and '^a&o' format strings for g_variant_new() and
g_variant_get().
https://bugzilla.gnome.org/show_bug.cgi?id=654955
Previously, when a binary did not run a single test - for whatever
reason, from the binary not existing to the binary not using the gtester
framework - no failures were recorded. Now we record a non-successful
run of a binary that did not start any tests as a failure, too.
Note that this does not change the behavior of any binaries that exit
successfully or that report the start of any gtester test.
Previously, gtester used the testcase_fail_count as the number of tests
that failed in the latest run testcase, but then use that as the return
value of main().
Now we count the failed testcases of the whole run.
This function implements the following logic:
if (g_variant_is_floating (value))
g_variant_ref_sink (value);
which is used for consuming the return value of callbacks that may or
may not return floating references.
This patch also replaces a few instances of the above code with the new
function (GSettings, GDBus) and lifts a long-standing restriction on the
use of floating values as the return value for signal handlers by
improving g_value_take_variant().
https://bugzilla.gnome.org/show_bug.cgi?id=627974
The function can be used to let regex compile non-NUL-terminated
strings without redesigning the way the pattern is stored in GRegex
objects and retrieved with g_regex_get_pattern.
https://bugzilla.gnome.org/show_bug.cgi?id=615895
The -e parameter to echo isn't recognized by echo in POSIX sh,
but isn't needed when no escaped characters need to be
interpreted.
This fixes building glib with a mingw cross compiler on Mac OS X.
https://bugzilla.gnome.org/show_bug.cgi?id=654085
The Linux eventfd() call is basically tailor made for the main loop
wake up pipe - all we want is a threadsafe way to write to a file
descriptor, and wake up the context on the other end; we don't care
about the content at all.
The eventfd manual page basically explains the benefits:
Applications can use an eventfd file descriptor instead of a
pipe (see pipe(2)) in all cases where a pipe is used simply to
signal events. The kernel overhead of an eventfd file
descriptor is much lower than that of a pipe, and only one file
descriptor is required (versus the two required for a pipe).
When writing my multithreaded spawn test case I actually hit the 1024
file descriptor limit quickly, because we used 2 fds per main context.
This brings that down to 1.
https://bugzilla.gnome.org/show_bug.cgi?id=653140
There is no chance that an unsigned integer value will be negative after
we do the bounds check that enforces its non-negativity.
Caught by Matthias running Coverity.
Running gthread/tests/spawn-multithreaded in a loop, I very easily hit:
GLib-CRITICAL **: g_main_context_wakeup: assertion `g_atomic_int_get (&context->ref_count) > 0' failed
Testing the refcount still left a window where we would fall into the
assertion. Fix this by just locking the context.
We should by default reset signal handlers; particularly with the
ability to install them via g_unix_signal_source_new(), we don't
want to call a user callback inside a fork()ed helper process.
https://bugzilla.gnome.org/show_bug.cgi?id=652072
I was debugging gthread/tests/spawn-multithreaded.c, and while I
don't think I actually hit EINTR in any of these cases, it'd be
good to fix them anyways.
https://bugzilla.gnome.org/show_bug.cgi?id=652072
