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::Error
s returned by these methods be deferred untilspawn()
? I think doing it immediately is better to indicate errors (for invalid signals) immediately. - Should
CommandExt::signal_mask
be marked unsafe? See discussion here.
Future directions:
- This can be extended to support
setsigdefault
as 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.