First, there's no reason not to use the new `epoll_create1` system call,
which quickly obsoleted `epoll_create` which has an obsolete and
unused size argument.
But more specifically, it offers `EPOLL_CLOEXEC` which we want
to use for general hygeine - there's no reason to potentially
leak this file descriptor to forked processes.
(GLib itself carefully closes file descriptors when forking child
processes, but it may be linked with other software that doesn't;
notably in my case for example the Rust standard library does not
do this and hence relies more on the application code using
`O_CLOEXEC` and variants)
This is just a drive-by fix; I saw the system call when I was using
`strace` to debug something else in rpm-ostree.
GParamSpec nicks and blurbs are effectively a deprecated feature,
or at least unused by most libraries these days. Since a number
of C libraries (i.e. GTK4) have started to null these out, annotate
them as `(nullable)` so bindings can do the same.
Closes#2719
For all the memory allocator APIS, document
that they terminate the program on failure.
This was so far only mentioned in the long description,
and in the docs for g_try_malloc(). And with gi-docgen
style docs, the long description is going away.
This utility function will be called by both launch_uris and
launch_uris_async, passing a from_task parameter respectively
as NULL and non-NULL. The from_task parameter will be needed
to know whether GAppLaunchContext signals should be emitted
directly (from_task == NULL) or scheduled for emission on the
main thread (from_task != NULL).
All of these warnings indicate programmer error, so critical is most
appropriate here.
Exceptions: deprecation warnings are just warnings. Also, warnings that
are worded with uncertainty can remain warnings rather than criticals.
Using the Application Activation Manager coclass. Its threading model
is marked as 'both', so it can be instantiated in any apartment type
without marshaling.
glib_debug is an auto option. This is clever because it allows us to
guess the best default based on the build type, while also allowing an
easy way to override if the guess is not good. Sadly, the attempt to
guess based on the build type does not work well. For example, it
considers debugoptimized builds to be debug builds, but despite the
name, it is definitely a release build type (except on Windows, which
we'll ignore here). The minsize build type has the exact same problem.
The debug option is true for both build types, but this only controls
whether debuginfo is enabled, not whether debug extras are enabled.
The plain build type has a different problem: debug is off, but the
optimization option is off too, even though plain builds are distro
builds are will almost always use optimization.
I've outlined an argument for why we should make these changes here:
https://blogs.gnome.org/mcatanzaro/2022/07/15/best-practices-for-build-options/
Specifically, Rule 4 shows all the build types and whether they
correspond to release builds or debug builds. Rule 6 argues that we
should provide good defaults for plain builds.
A file-descriptor was created with the introduction of pidfd_getfd() but
nothing is closing it when the source finalizes. The GChildWatchSource is
the creator and consumer of this FD and therefore responsible for closing
it on finalization.
The pidfd leak was introduced in !2408.
This fixes issues with Builder where anon_inode:[pidfd] exhaust the
available FD limit for the process.
Fixes#2708
