Transparently retrying `Interrupted` `waitpid` calls is not always appropriate

[nagisa]

NB: this issue is just some rambling based on some drive-by review I've done elsewhere. I think its a genuine and useful thing to track, but its not something I hold strong opinions about.

Currently the Child::wait call on UNIX systems is implemented to retry in case the waitpid call gets interrupted, due to its use of cvt_r:

rust/library/std/src/sys/unix/process/process_unix.rs

Lines 434 to 443 in d4ea0b3

	pub fn wait(&mut self) -> io::Result<ExitStatus> {
	use crate::sys::cvt_r;
	if let Some(status) = self.status {
	return Ok(status);
	}
	let mut status = 0 as c_int;
	cvt_r(|| unsafe { libc::waitpid(self.pid, &mut status, 0) })?;
	self.status = Some(ExitStatus::new(status));
	Ok(ExitStatus::new(status))
	}

I'd like to argue that this is not always correct or appropriate. For instance, consider implementation of a service manager (a-la systemd, supervisord, etc.) Such a thing will in general want to register signal handlers and then forward some of the signals to some of the managed processes. With Child::wait retrying automatically the tool wanting to do something on a signal is forced to either drop down to directly calling the libc functions or to avoid the Child::wait altogether.