[Question] Exiting from a thread in a signal handler

[mrcnski]

Hello. Thank you for the delightful blog posts about signals -- that was a fun rabbithole.

I have what is (hopefully) a simple question: is it safe to call pthread_exit in register?

For background, I'm trying to handle a "thread-directed" signal (SIGSYS from seccomp) in a thread that does blocking work, and therefore can't use signal-hook's abstractions (AFAIK). I'm hoping to return a value from the single thread rather than just terminate the process.

[vorner]

Hello

I'd say that most probably no, it is not. For several reasons:

• Most importantly, it is not listed in the signal-safety list https://man7.org/linux/man-pages/man7/signal-safety.7.html.
• Reading through the documentation, that function calls a lot of things in a "plugin"-style way ‒ it calls cleanup handlers created by pthread_cleanup_push and it calls destructors for any relevant thread-local resources. While, in theory, one could ensure that all that stuff is signal safe, it would be really hard to do in practice since any library linked into the process may set up its own thread-local resources (quite common in Rust) and may use the cleanup functions (AFAIK rather rare). Both of these might use dynamic memory internally, to manipulate the lists of these things.
• In any way, calling this function (no matter if from a signal handler or not) in Rust is probably going to be a bad idea, since the thread is simply terminated without unwinding the stack and running destructors. While this is not UB technically, it would very likely leak a lot of resources, may leave mutexes locked forever, etc.

But looking at the documentation of when a thread might get a SIGSYS, I think one possible solution would be to either ignore the signal and let the syscall fail for the process (and then hope error handling is correct and the thread gracefully reaches some sane error state / return value) or block the signal for the thread and pick it up later with something like sigwait.

And you're right, signal-hook isn't really the tool for this particular job.

[mrcnski]

Thanks for the informative answer! Quite interesting, though I appreciate your work in shielding Rust developers from these details.

In our case, we determined that instead of using the SECCOMP_RET_TRAP action, having seccomp kill the process is acceptable, if somewhat suboptimal. Cheers!