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
I was stracing the timeout replacement and found it spams wait4 and clock_nanosleep calls.
Problematic code is:
fn wait_or_timeout(&mut self, timeout: Duration) -> io::Result<Option<ExitStatus>> {
if timeout == Duration::from_micros(0) {
return self.wait().map(Some);
}
// .try_wait() doesn't drop stdin, so we do it manually
drop(self.stdin.take());
let start = Instant::now();
loop {
if let Some(status) = self.try_wait()? {
return Ok(Some(status));
}
if start.elapsed() >= timeout {
break;
}
// XXX: this is kinda gross, but it's cleaner than starting a thread just to wait
// (which was the previous solution). We might want to use a different duration
// here as well
thread::sleep(Duration::from_millis(100));
}
Ok(None)
}
The original C variant gets away without doing anything of the sort.
Now, I'm not particularly good with rust but would be genuinely surprised if this was really necessary.
One clean solution would be to grab a file descriptor for the child (see the CLONE_PIDFD flag to clone) and one for timerfd. Then the code could nicely wait in an event loop.
I would implement this myself but I'm atrocious at Rust.
If stuff like the above kind be used, what's the reasoning?
While the comment above acknowledges the current state is not good, it does not justify it.
The text was updated successfully, but these errors were encountered:
I was stracing the timeout replacement and found it spams wait4 and clock_nanosleep calls.
Problematic code is:
The original C variant gets away without doing anything of the sort.
Now, I'm not particularly good with rust but would be genuinely surprised if this was really necessary.
One clean solution would be to grab a file descriptor for the child (see the CLONE_PIDFD flag to clone) and one for timerfd. Then the code could nicely wait in an event loop.
I would implement this myself but I'm atrocious at Rust.
If stuff like the above kind be used, what's the reasoning?
While the comment above acknowledges the current state is not good, it does not justify it.
The text was updated successfully, but these errors were encountered: