We previously hold a lock in the loop that collects the arguments for
g_signal_emit(), which we drop before calling into the argument
collection functions and reacquire again at the bottom of the loop (ie:
one release/acquire pair for each argument collected). To make matters
worse, the lock is just released again after the loop.
Presumably that was done to protect the access to the parameter array,
but it's pretty unlikely that this is needed because the only way it
changes is if the signal is unloaded. That only happens when unloading
types which is quite unlikely to happen while we are emitting on an
instance of that type (and, as an aside, never happens anymore anyway).
If we move the unlock below the loop up above it and remove the
acquire/release pair from the loop, we improve performance in the new
arg-collecting performance tests by ~15% (more like ~18% in the case
where we only emit to one handler -- where argument collection dominates
more).
https://bugzilla.gnome.org/show_bug.cgi?id=694380
While those strings ("Expecting 1 control message, got %d" and
"Expecting one fd, but got %d\n") have same singular/plural form
in english, it is not necessarily the case in other languages.
https://bugzilla.gnome.org/show_bug.cgi?id=695233
It's a recipe for race conditions and error; on some hardware
architectures one thread isn't guaranteed to see the results
of writes from another thread without a cache flush.
https://bugzilla.gnome.org/show_bug.cgi?id=700855
Windows doesn't define STDOUT_FILENO and STDERR_FILENO, and they're
not even guaranteed to be 1 and 2. So just use stdio instead. Also fix
a counting error. Pointed out on gtk-devel-list.
The test /gdbus/connection/large_message waits for a dbus name to appear.
The dbus name is created by a another process executed in the background.
If for some reason this fails, the test will likely wait forever.
This will avoid this situation by making the test fail if the dbus service
has not appeared after 10 seconds.
https://bugzilla.gnome.org/show_bug.cgi?id=698981
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
It tries to run glib-compile-schemas and glib-mkenums, which
we won't have in the runtime tree.
Anyways it's kind of a dumb test since the best test for
compilation tools is...compiling things, which we already
do frequently.
Since we expect them to crash, let's not spam the system
core dump collection (systemd, abrt). At the moment
systemd is not very robust against programs crashing
in loops.
Instead of aborting, we exit(1).
https://bugzilla.gnome.org/show_bug.cgi?id=700714
See https://live.gnome.org/GnomeGoals/InstalledTests for more
information.
The tests now support being run both uninstalled and installed, so
'make check' works for those who want it. For tests which need data
files, the way this works is they look in the compiled in value of
SRCDIR by default, and the generated tests use "env G_TEST_DATA=" to
override that.
This patch only converts glib/tests for now; if this patch looks good,
I'll do the rest of the tests.
https://bugzilla.gnome.org/show_bug.cgi?id=699079
Rather than overloading --verbose, just skip the tests that aren't
supposed to be run in the parent process (so that if you do run the
toplevel test with --verbose, it doesn't immediately error out).
https://bugzilla.gnome.org/show_bug.cgi?id=679683
g_test_trap_fork() doesn't work on Windows and is potentially flaky on
unix anyway given the fork-but-don't-exec. Replace it with
g_test_trap_subprocess(), which re-spawns the same program with
arguments telling it to run a specific (otherwise-ignored) test case.
Make the existing g_test_trap_fork() unit tests be unix-only (they
never passed on Windows anyway), and add a parallel set of
g_test_trap_subprocess() tests.
Also fix the logic of gtestutils's "-p" argument (which is used by the
subprocess tests); previously if you had tests "/foo/bar" and
"/foo/bar/baz", and ran the test program with "-p /foo/bar/baz", it
would run "/foo/bar" too. Fix that and add tests.
https://bugzilla.gnome.org/show_bug.cgi?id=679683
