As we start moving documentation over from gtk-doc to gi-docgen, the
gtk-doc coverage is going to go down and things are going to start
breaking. That’s OK; we don’t need to test it any more.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #3037
The files here are copied from the docs-gtk-org
branch of gtk.
This adds gi-docgen to the CI Dockerfiles and ensures the new versions
(including the OS upgrades from the previous commit) are used during CI.
Helps: #3037
That means Debian Bookworm and Fedora 37.
Also rework the mingw Dockerfile to be based on the Fedora one, so that
the underlying layers can be shared. This should reduce the disk
consumption of the registry a little.
`.gitlab-ci.yml` has not been updated to use the new images in this
commit, as the images will be modified further in the following commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We can't easily use g_autofd with g_unix_open_pipe, because its
parameter is an array of two fds that both need closing. Add an inline
convenience wrapper providing the obvious semantics.
Signed-off-by: Simon McVittie <smcv@collabora.com>
g_clear_fd() is documented to be async-signal safe whenever the
fd is either negative or valid (which it should be here) and the error
is NULL (which it always is here).
Signed-off-by: Simon McVittie <smcv@collabora.com>
It's not very likely, but there is a small chance that an
incoming signal could disturb the non-blocking read calls in
g_wakeup_acknowledge, leading to a subsequent spurious wake up.
This commit addresses the problem by doing the usual EINTR
loop (which is already present on the write side incidentally)
Previously, this would loop as long as read() got the expected number of
bytes back, which is 8. That means every successful read() of the eventfd
would perform an additional syscall() as a followup.
This is not ideal because eventfd (unless used as an EFD_SEMAPHORE) will
reset the counter as part of the read(). So that means that we either do
an additional throw-away syscall() or potentially race against a producer
generating new events before this change.
Currently the GSourceList has it's own allocation plus a secondary
allocation for the GList which contains it (from GMainContext). Not only
are these a pointer chase, but they are on separate cachelines too. Without
changing the code much we can at least keep things on the same cacheline
so that the pointer chase matters less.
Since the GList becomes embedded in the GSourceList you can use a
g_queue_unlink() directly removing the link without traversing the GList
like was done before.
Furthermore, we can simplify some code with g_queue_push_tail_link()
instead of some extra branching.
I'm not aware of any platforms where this is a problem in practice, but
it's definitely nonportable and doesn't hurt to document it.
I wonder about CHERI....
This should not result in any functional changes, but will eventually
allow glib to be functional on CHERI-enabled systems such as Morello.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
These functions can be used to initalize pointer-type variables rather
than a gsize. This is required to support CHERI-enabled platforms where
gsize cannot be used to store pointers. Follow-up changes will migrate
the uses of g_once_init that store pointers to the new API
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
