Tracking issue for Child::try_wait

[alexcrichton]

Introduced in #38866 this is a tracking issue for the Child::try_wait method.

This method attempts to wait for a child and collect its status but does not block. Questions for stabilization include:

• Is the method name suitable?
• Is the return type suitable? (io::Result<T> vs io::Result<Option<T>>)

[SimonSapin]

If this does not block, there’s not waiting involved?

[oconnor663]

One problem I'm grappling with right now is how to wait on a child (in one thread) while leaving open the option of killing it later (from another thread) if it hasn't exited yet. Right now the wait method takes &mut self, so there's no way to call kill (which also takes &mut self) if someone's waiting on wait, and it would be a race condition anyway. The Unix way seems to be listening to SIGCHILD, but that assumes I own the whole process's signal handlers, and I don't want to assume that in library code.

try_wait will help. I can call that in a loop with sleeps in-between. That's doesn't feel great, but it's what Python does. A perfect solution might be to call the newer waitid function with WNOWAIT, which waits without reaping the child, to avoid racing against kill. But that one might not be defined on all platforms? I'm not sure yet. It does seem like it'll be easier to use waitid out of tree where available, since it's still safe (actually necessary to avoid leaks?) to call the child's wait afterwards.

If it's true that waitid "subsumes the rest of the wait* family" (according to that link above), it might be nice to expose it at some point? I wouldn't want to derail this issue with that question, but I'm interested in thinking about what it would look like. If a hypothetical future wait_without_waiting method/koan took &self, it would still be impossible to call kill while another thread was waiting. What API would make that possible? Maybe returning some sort of KillHandle that borrows the Child? I think it's unspecified what happens if multiple threads are waiting at once on the same child, so preventing that might be a good thing.

[alexcrichton]

@oconnor663 what you're trying to do is inherently race-prone on Unix and &mut is simply expressing that. A pid is consumed in the ownership sense once wait succeeds, so a call to kill could be a use-after-free if it's not synchronized with wait.

It does indeed sound like waitid would be quite nice! If it's implemented across platforms then I think we could definitely start using it and consider relaxing &mut self and such.

[oconnor663]

Golang added (private) support for waitid six months ago, and it looks like they only did it on Linux. Ah well.

[oconnor663]

Hmm, rust-lang/libc#489 seems to have included Mac support though. I'll play with it. (Interesting timing!)

[oconnor663]

Thinking more about how I'm going to expose a similar API in duct. I think I'm going to opt for io::Result<Option<ExitStatus>>. My reasoning is that most callers are going to want to short-circuit on "real errors", and I want them to look like this

if let Some(status) = foo.try_wait()? {
    ...
} else {
    ...
}

instead of like this

match foo.try_wait() {
    Ok(status) => {
        ...
    }
    Err(err) if err.kind() == io::ErrorKind::WouldBlock => {
        ...
    }
    Err(err) => return Err(err),
}

The non-blocking Read and Write APIs don't work this way, because they have to support both blocking and non-blocking callers in the same function signature, and it's nasty to force the common blocking case to unwrap an Option. But the try_wait API here is never blocking, and probably none of its callers are going to want to treat the WouldBlock condition as a real error.

Name-wise, I agree with @SimonSapin that the term "try_wait" is kind of confusing, though I guess it's consistent with what libc calls everything, and with the Mutex API. (The gold medal winner for confusing names in this part of the standard has got to be waitid(...WNOWAIT).) I could see check or poll? But those don't really convey the "and also clean up the child if it's finished" part of the function, which is pretty important.

[alexcrichton]

@oconnor663 good point about using Option instead of just io::Result!

Also yeah the name is mostly inspired by mutexes and other nonblocking/opportunistic operations which are prefixed with try_ (e.g. try_recv, try_borrow, etc)

[oconnor663]

@alexcrichton would you be interested in a PR that tried out the Option approach?

[alexcrichton]

Oh oops I thought that it already did that actually. Sure if you want to send a PR sounds good to me!