An interruption handler is difficult to code properly to ensure that the interrupted thread stay in a consistent and safe state.
If Rust want to be able to safely handle signals (as it safely handle threads) we probably need to create a new trait for closure (e.g.
FnAsync). This function type must be reentrant and so, should only be allowed to mutate external/global objects wrapped in a dedicated type (i.e.
volatile sig_atomic_t), something similar as
Arc but for safe interruptions, not thread. Another way is not to allow global object modification (i.e. pure function), but this only move the problem to the raw interrupt handler (calling the closure).
To be consistent, this new function type should only be allowed to call reentrant functions as well.
This also impact the memory manager (i.e. jemalloc). Heap allocation should be prohibited in this type of function to avoid inconsistent memory layout (when malloc/free is interrupted). The
core lib should help here.
A safe interruption handler seems to be hard to achieve as a generic way because of the async-signal-safe FFI (cf. signal(7)) and some special cases as the
errno variable, but I think Rust have the potential to code safely, even this kind of asynchronous function call.
Other problems remains (stack allocation, EINTR error handling…) but this
FnAsync seems to be the more tricky.
This safety problem may impact some Rust internals and should be discuss to be able to get a future-proof Rust 1.0.