We have g_int_hash()/g_int_equal(), which in practice might also work
with with pointers to unsigned integers. However, according to strict
interpretation of C, I think it is not valid to conflate the two.
Even if it were valid in all cases that we want to support, we should
still have separate g_uint_{hash,equal} functions (e.g. by just #define
them to their underlying g_int_{hash,equal} implementations).
Add instead internal hash/equal functions for guint.
Previously thread-pool-slow ran a single test which encoded a state
machine and polling timer to run 8 different sub-tests and check for
their exit conditions.
This was a bit ugly, and since the timer ran at 1s granularity, several
of the tests completed quite fast and then hang around for most of 1s
before finishing and moving to the next test.
Split the test functions up into separate GTest tests, and split the
state machine up between the test functions. All of the `GMainLoop`
handling is actually only needed for the `test_threadpool_idle_time()`
test.
This reduces the overall test runtime from 36s to 19s on my machine,
with 17s of that being spent in `test_threadpool_idle_time()`.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #2810
This makes things a bit more maintainable, as there’s less global state
to worry about.
It introduces no functional changes.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
The race was already acknowledged in the code (via `last_failed`): the
thread pool starts dequeuing jobs as soon as it’s created, so it’s
dequeuing the sorted thread IDs while they’re still being enqueued and
sorted. This can lead to them being dequeued out of the expected order
if new thread IDs are enqueued out of order, which is possible because
they’re randomly generated.
The test tried to handle this by allowing one out-of-order dequeue, but
it looks like the race can race hard enough that multiple out-of-order
dequeues are possible.
Fix that by only starting to dequeue the jobs from the thread pool once
they’ve all been enqueued and put in a total order.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #2810
The test only needs a unidirectional channel, and a pipe is sufficient
for that.
This may simplify things when running the test on Hurd; see
https://gitlab.gnome.org/GNOME/glib/-/issues/3148#note_1874198.
Additionally, set `O_NONBLOCK` on the pipe since the test seems to
expect that partial writes will succeed and that writes to a full buffer
will fail rather than block.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3148
Various parts of the build (such as `objectmanager-rst-gen`) depend on
running `gdbus-codegen` after it’s been built, but they currently only
encode a dependency to the main codegen Python file and not the
supporting files. This can cause `gdbus-codegen` to fail with an
`ImportError` if the build races so that `objectmanager-rst-gen` is
built before the codegen supporting files.
Example failure here: https://gitlab.gnome.org/pwithnall/glib/-/jobs/3266471
```
FAILED: gio/tests/gdbus-object-manager-example/objectmanager-rst-gen-org.gtk.GDBus.Example.ObjectManager.Animal.rst gio/tests/gdbus-object-manager-example/objectmanager-rst-gen-org.gtk.GDBus.Example.ObjectManager.Cat.rst
/usr/bin/python3 gio/gdbus-2.0/codegen/gdbus-codegen --interface-prefix org.gtk.GDBus.Example.ObjectManager. --generate-rst objectmanager-rst-gen --output-directory gio/tests/gdbus-object-manager-example ../gio/tests/gdbus-object-manager-example/gdbus-example-objectmanager.xml
Traceback (most recent call last):
File "/builds/pwithnall/glib/_build/gio/gdbus-2.0/codegen/gdbus-codegen", line 53, in <module>
from codegen import codegen_main
File "/builds/pwithnall/glib/_build/gio/gdbus-2.0/codegen/codegen_main.py", line 29, in <module>
from . import dbustypes
File "/builds/pwithnall/glib/_build/gio/gdbus-2.0/codegen/dbustypes.py", line 22, in <module>
from . import utils
ImportError: cannot import name 'utils' from 'codegen' (/builds/pwithnall/glib/_build/gio/gdbus-2.0/codegen/__init__.py)
```
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
The GIR files are now built by GLib itself, so they will be in the build
directories of each sub-library, except for GLib-2.0 which is built
alongside GObject-2.0.
All the calls to `usage()` are immediately followed by a `return` from
`main()` which sets an appropriate exit status.
Calling `exit()` early means that running `gio --help` returns exit
status 1, which is incorrect — it should (by convention) return 0.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
If the string of one log domain is contained in
another, it was printing both.
For example, if G_MESSAGES_DEBUG is "Gtkspecial",
it would also keep the logs of the "Gtk" domain
Depending on the operating system, /bin/sh might either be bash (for
example on Fedora or Arch) or dash (for example on Debian or Ubuntu)
or some other POSIX shell.
When bash is asked to run a simple command with no shell keywords or
metacharacters, like this one, it replaces itself with the program
via execve(), but dash does not have that optimization and treats it
like any other program invocation in a larger script: it will fork,
exec the program in the child, and wait for the child in the parent.
This seems like it conflicts with sleep_and_kill() assuming that it can
use the subprocess's process ID as the sleep(1) process ID. Specifically,
if it sends SIGKILL, it will go to the sh(1) process and not the sleep(1)
child, which could result in the sh(1) process being terminated and
its sleep(1) child being leaked.
To get the bash-like behaviour portably, explicitly use the exec builtin
to instruct the shell to replace itself with sleep(1), so that the
process ID previously used for the shell becomes the process ID of the
sleep process.
This appears to resolve an intermittent hang and test timeout on Debian
machines (especially slower ones), although I'm not 100% clear on the
mechanics of how it happens.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3157
Signed-off-by: Simon McVittie <smcv@collabora.com>
The weak symbol resolution doesn’t seem to work (see
https://gitlab.gnome.org/GNOME/glib/-/jobs/3265405):
```
Undefined symbols for architecture x86_64:
"___lsan_enable", referenced from:
_g_leak_sanitizer_is_supported in gutils.c.o
"___lsan_ignore_object", referenced from:
_g_ignore_leak in gquark.c.o
_g_ignore_leak in gthreadpool.c.o
_g_ignore_leak in gutils.c.o
_g_leak_sanitizer_is_supported in gutils.c.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
See !3672
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
`test-generated.txt` is listed in `test.gresource.xml`, so it needs to
be specified as a dependency in the `custom_target()` which uses
`test.gresource.xml`.
Fixes intermittent build failures like:
```
FAILED: gio/tests/test.gresource
/builds/GNOME/glib/_build/gio/glib-compile-resources --compiler=gcc --target=gio/tests/test.gresource --sourcedir=/builds/GNOME/glib/gio/tests --sourcedir=/builds/GNOME/glib/_build/gio/tests --internal ../gio/tests/test.gresource.xml
../gio/tests/test.gresource.xml: Failed to locate test-generated.txt in any source directory.
```
See !3671 and #3163.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
This reverts commit 0b9900e4e7.
The dependency was added in the wrong place: `test-generated.txt` is
needed when compiling `test.gresource`, not when compiling the test
which ultimately uses that gresource.
See !3671 and #3163.
