signal(2) is annoying to use because the signal handler is restricted
to a limited set of async-signal-safe functions (see signal-safety(7)).
For example, the signal handler might be called while the same thread
is halfway through a call to malloc(), so it is not necessarily safe
for it to allocate memory - which is a problem, because g_idle_add()
almost certainly allocates memory.
Solving this portably would require tricky Unix code like the
implementation that's behind g_unix_signal_source_new() (which we
can't use directly here, because it is documented not to support
SIGQUIT, SIGCONT or SIGTSTP). However, Flatpak is Linux-specific, and
Linux since at least 2.6.27 (2008) implements signalfd(), which delivers
signals into a poll()-based main loop - exactly what we want here.
I'm assuming here that nobody cares about Linux < 2.6.27 kernels or glibc < 2.9 any more.
This implementation assumes that flatpak-xdg-utils is just as Linux-specific as Flatpak itself. If it's intended to be buildable on non-Linux kernels like *BSD (see #30 for one reason why that might make some sense), then some build-system glue will be needed to disable compilation of flatpak-spawn on non-Linux.
signal(2) is annoying to use because the signal handler is restricted to a limited set of async-signal-safe functions (see signal-safety(7)). For example, the signal handler might be called while the same thread is halfway through a call to malloc(), so it is not necessarily safe for it to allocate memory - which is a problem, because g_idle_add() almost certainly allocates memory.
Solving this portably would require tricky Unix code like the implementation that's behind g_unix_signal_source_new() (which we can't use directly here, because it is documented not to support SIGQUIT, SIGCONT or SIGTSTP). However, Flatpak is Linux-specific, and Linux since at least 2.6.27 (2008) implements signalfd(), which delivers signals into a poll()-based main loop - exactly what we want here.
Resolves: https://github.com/flatpak/flatpak-xdg-utils/issues/29
I'm assuming here that nobody cares about Linux < 2.6.27 kernels or glibc < 2.9 any more.
This implementation assumes that flatpak-xdg-utils is just as Linux-specific as Flatpak itself. If it's intended to be buildable on non-Linux kernels like *BSD (see #30 for one reason why that might make some sense), then some build-system glue will be needed to disable compilation of flatpak-spawn on non-Linux.