The changes made in commit bc59e28bf6
(issue #3399) fixed introspection of the GThread API. However, they
introduced a trampoline in every threading function. So with those
changes applied, the disassembly of `g_mutex_lock()` (for example) was:
```
0x7ffff7f038b0 <g_mutex_lock> jmp 0x7ffff7f2f440 <g_mutex_lock_impl>
0x7ffff7f038b5 data16 cs nopw 0x0(%rax,%rax,1)
```
i.e. It jumps straight to the `_impl` function, even with an optimised
build. Since `g_mutex_lock()` (and various other GThread functions) are
frequently run hot paths, this additional `jmp` to a function which has
ended up in a different code page is a slowdown which we’d rather avoid.
So, this commit reworks things to define all the `_impl` functions as
`G_ALWAYS_INLINE static inline` (which typically expands to
`__attribute__((__always_inline__)) static inline`), and to move them
into the same compilation unit as `gthread.c` so that they can be
inlined without the need for link-time optimisation to be enabled.
It makes the code a little less readable, but not much worse than what
commit bc59e28bf6 already did. And perhaps
the addition of the `inline` decorations to all the `_impl` functions
will make it a bit clearer what their intended purpose is
(platform-specific implementations).
After applying this commit, the disassembly of `g_mutex_lock()`
successfully contains the inlining for me:
```
=> 0x00007ffff7f03d80 <+0>: xor %eax,%eax
0x00007ffff7f03d82 <+2>: mov $0x1,%edx
0x00007ffff7f03d87 <+7>: lock cmpxchg %edx,(%rdi)
0x00007ffff7f03d8b <+11>: jne 0x7ffff7f03d8e <g_mutex_lock+14>
0x00007ffff7f03d8d <+13>: ret
0x00007ffff7f03d8e <+14>: jmp 0x7ffff7f03610 <g_mutex_lock_slowpath>
```
I considered making a similar change to the other APIs touched in #3399
(GContentType, GAppInfo, GSpawn), but they are all much less performance
critical, so it’s probably not worth making their code more complex for
that sake.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3417
As per https://gitlab.gnome.org/GNOME/glib/-/issues/3421#note_2206315:
It seems like there’s agreement that glib_debug should be enabled for
developers and disabled for distros; and it also seems like there’s no
reliable way to figure this out magically (because not everyone ties
things to `-Dbuildtype=*`). So, we’re left with forcing some group of
people to manually set the value of `glib_debug`. There are more
developers/contributors than there are distros, and distros are more
likely to notice an accidentally-slow GLib package than developers are
likely to notice an accidentally-not-asserting-hard-enough local build,
so let’s say:
The default should be `-Dglib_debug=enabled`, and distros should probably
all override that to `-Dglib_debug=disabled`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3421
This kind of deeply nested menu is definitely no longer good UI practice
for most apps (deeply nested menus make things hard to find, and require
good mouse control to navigate). However, it does serve as a good
demonstration of the concepts in `GMenuModel`, so keep it, with a
sentence to acknowledge that it’s not a good UI.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3451
Because `epoll_create1()` is what the code in `giounix-private.c`
actually uses.
Spotted by Xuntao Chi.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3450
These tests are expected to cause a thread to deadlock. That seems to be
fine with glibc on Linux, but the glibc version on FreeBSD can detect
the deadlock, and aborts the whole test process with:
```
GLib (gthread-posix.c): Unexpected error from C library during 'pthread_mutex_lock': Resource deadlock avoided. Aborting.
```
This is fair enough.
To avoid this causing the test suite to fail, run those two tests in
subprocesses. This also means we’re not carrying a deadlocked thread
around for the rest of the test suite.
Improves on commit 62192925b6.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
And size it to `sysconf (_SC_MINSIGSTKSZ)`, if defined.
This might fix the sigaltstack test on muslc, as suggested by Markus
Wichmann (https://www.openwall.com/lists/musl/2024/05/30/2) and Rich Felker
(https://www.openwall.com/lists/musl/2024/05/29/7) on the musl mailing
list.
The thinking is that the CI machine might have a huge register file
(AVX512 or some other large extension) which doesn’t fit in `MINSIGSTKSZ`.
By sizing the alternate stack to `sysconf (_SC_MINSIGSTKSZ)` we should
be able to avoid that.
Moving it onto the heap should avoid any potential complications or bugs
from having one stack embedded within another.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3315
Provide examples of what they all represent, and expand on the
descriptions of them in a few places.
Move references to their equivalents from `GnomeVFS` to lower down in
the documentation, since `GnomeVFS` has been deprecated for many years
now, and is unlikely to be pertinent to most readers.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This function type isn't only used by g_hash_table_foreach_remove(), and
what happens to the data when we return TRUE depends on the calling
function.
Includes a port to modern gi-docgen syntax by Emmanuele Bassi.
Signed-off-by: Adrien Plazas <adrien.plazas@codethink.co.uk>
When listing schemas from a specified directory, explicitly
create the GSettings object from the schema, don't allow g_settings_new
to do the usual lookup. That lookup fails if no other schemas are
installed in the default directories.
Fixes#3429.
This can never have been tested, it was returning `GUnixMountEntry`
structs from functions which are typed to return `GUnixMountPoint`s.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
While GLib doesn’t parse these files, it does provide API to access the
fields from them, and does implement some logic based on options fields
in them. It would be nice to be able to test that, and get coverage of
the methods for `GUnixMountPoint` and `GUnixMountEntry`.
We don’t expect users to start querying the fstab or mtab by explicitly
loading data from those file paths. These functions are mainly intended
to prove a controllable entry point into the `gunixmounts.c` code for
unit testing.
It means we can provide a file with controllable contents in order to
test the mount entry/point code on.
See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4155
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
