You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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), like ctrlc and tokio does, as this is definitely safe. Trying other things that are in the white list may not be worthwhile.
For those syscalls that are signal-safe, their Nix wrappers may not be.
For example,
stat(2)
is signal-safe, its Nix wrapper uses theNixPath
trait, which will allocate if the passed argument has a length greater thanMAX_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.
The text was updated successfully, but these errors were encountered: