The dangerous interaction between signals and other functions is outside of what Rust can help with.
Rust doesn't have an effect system nor a similar facility to flag what code is not signal-handler-safe. A Rust implementation could just as likely call something incompatible.
Rust has many useful guarantees, and is a significant improvement over C in most cases, but let's be precise about what Rust can and can't do.
My understanding is that a sound implementation of signal handling in Rust will require the signal handler to be Send, requiring it only has access to shared data that is Sync (safe to share between threads). I guess thread-safe does not nessecarily imply signal-safe, though.
And of course you could still call to a signal-unsafe C function but that requires an unsafe block, explicitly acknowledging that Rust's guarentees do not apply.
Of course, you are still trusting that the implementation is sound.
While this is a common misconception, I'm already tired of enthusiastic "safu language fans" trying to explain what bound checks mean to me so apologizes for being mean.
But no, in 2024 you should focus on temporal memory safety which is much harder to eliminate compared to "just add boundz CHK everYwHErE!!!@".
