-
Notifications
You must be signed in to change notification settings - Fork 24
Description
Proposal
Currently, when Rust spawns a process on Unix, it always sets the signal mask to the empty set.
posix_spawn: https://github.com/rust-lang/rust/blob/7fe2c4b00dfbc33643e1af4b293eb057306a8339/library/std/src/sys/unix/process/process_unix.rs#L532-L539fork/exec: https://github.com/rust-lang/rust/blob/7fe2c4b00dfbc33643e1af4b293eb057306a8339/library/std/src/sys/unix/process/process_unix.rs#L340
This proposal adds a way to set the signal mask for a process.
Motivation, use-cases
There are a variety of use cases for signal masks, but my own use case is to block SIGTSTP and other signals, to work around a flaw in the definition of posix_spawn. This is currently not possible to do with the Rust std::process::Command APIs.
Solution sketches
Proposed API, using the suggestion by @zackw in this comment:
pub trait CommandExt: Sealed {
// <...snip: existing methods here...>
fn block_signal(&mut self, signal: i32) -> io::Result<&mut std::process::Command>;
fn unblock_signal(&mut self, signal: i32) -> io::Result<&mut std::process::Command>;
fn will_block_signal(&self, signal: i32) -> io::Result<&mut std::process::Command>;
}I put up a PR with this API:
Questions:
- Should the
io::Errors returned by these methods be deferred untilspawn()? I think doing it immediately is better to indicate errors (for invalid signals) immediately. - Should
CommandExt::signal_maskbe marked unsafe? See discussion here.
Future directions:
- This can be extended to support
setsigdefaultas well. Currently we always setSIGPIPE.
Links and related work
Post in the internals group: https://internals.rust-lang.org/t/add-a-way-to-set-the-signal-mask-of-a-child-process/17220
What happens now?
This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals in its weekly meeting. You should receive feedback within a week or two.