flatpak-spawn: Make signal handling async-signal-safe #34
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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: flatpak#29 Signed-off-by: Simon McVittie <[email protected]>
smcv
force-pushed
the
async-signal-safety
branch
from
dd2dc6a to
cde4382
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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: #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.