Some Nix wrappers are not signal-safe
SteveLauC opened this issue · 2 comments
SteveLauC commented
For those syscalls that are signal-safe, their Nix wrappers may not be.
For example, stat(2)
is signal-safe, its Nix wrapper uses the NixPath
trait, which will allocate if the passed argument has a length greater than MAX_STACK_ALLOCATION
, and allocation is not signal-safe, making the wrapper signal-unsafe.
I kinda think we should take a look at those functions that are asked to be signal-safe by the standard, and check if the corresponding Nix wrappers are safe or not, if not, then we should document it so that our users can be aware.
SteveLauC commented
This should also be done in Nix 0.30.0 if I can make it.
SteveLauC commented
Tried this today, and I am not going to finish this because:
- Nix wrappers use std types, and we have no guarantee of signal safety there as this concept is for C, doesn't really apply to the Rust stuff.
- It might not be worth to do it as well. When using signal handlers, the only thing one might want to use is
libc::write(2)
, likectrlc
andtokio
does, as this is definitely safe. Trying other things that are in the white list may not be worthwhile.