Some operating systems have a concept of asynchronous signals -- an external events that can interrupt the control flow of a thread and cause it to execute a special function, called a signal handler. A control flow can be redirected into a signal handler from any point at which the signal is not blocked, which makes installing signal handlers very unsafe and requires caution while implementing a signal handler. C and C++ standards, as well as POSIX, specify what a signal is and what semantics they have, and what a signal handler can safely do.
I propose providing documentation what can a signal handler do in a Rust program, specifically:
What functions from the standard library (core and maybe std) can be called from a signal handler?
Allowed interactions with global objects. As far as I understand, a signal handler can only safely interact with immutable (without interior mutability) and atomic (core::sync::atomic) objects
Safety of using the Rust formatting subsystem (core::fmt) -- can it be safe, what types from the standard library can be safely formatted
Yeah, we should really document this more precisely.
On the opsem side, things behave largely like in C and C++ -- async signals (which also include HW interrupts) are considered basically "separate threads" with all the usual caveats (and data race UB) except that they are paired up with a "main" thread and have a special relationship with that thread (allowing the use of compiler_fence rather than fence when synchronizing with that thread).
Most of the rest of this is a libs question.
There, the tl;dr is that std APIs are generally not async-signal-safe.
It's good to document this, but documentation without caveats will encourage people to use signal handlers. Linux users should be encouraged to use other, safer means to handle signals (signalfd).
Unwinding runs destructors which can run arbitrary code. I'm not sure if low-level unwinding could work even if you didn't have any destructors - probably still wouldn't be guaranteed by the language because there's always a chance that it will need some incompatible OS API or lazily load and allocate unwind tables.
Panicking is totally incompatible with signal handlers, since it runs arbitrary code of panic handlers and mallocs PanicHookInfo.