Synchronous Windows stdin pipes broke tokio

[emilyalbini]

It was reported in tokio-rs/tokio#4670 that tokio::process::Command broke between nightly-2022-04-29 and nightly-2022-04-30 on Windows. According to the tokio authors that struct is a wrapper over the standard library's std::process::Command. Looking at the PRs between those two nightlies the likely cause seems #96441, as it touches pipes on the affected platform.

[emilyalbini]

We also hit this in #97088 (comment) when bumping RLS (which depends on tokio). @Mark-Simulacrum is going to revert this in the upcoming beta, and post a revert PR for master soon.

[Mark-Simulacrum]

Posted master revert (#97127) and added it to #97088 (targeting 1.62) as well.

[m-ou-se]

As I posted on tokio-rs/tokio#4670 (comment):

It's unfortunate that libraries depend on the child process pipes being asynchronous ones, since that wasn't a documented promise in std. It seems we have two ways forward:

1. Document that the .as_raw_handle() from a std::process::ChildStd{in,out,err} is always an asynchronous pipe on Windows. This means std has to spawn a thread to copy over data from the async pipe into a new sync pipe when the pipe is given to another Command. Or:

2. Document that we don't provide that guarantee, and wait for existing libraries to adapt before changing the actual implementation a few releases later.

For 2, we could add something like a .async_pipes(true) to std::os::windows::process::CommandExt so there's a way to explicitly request async pipes.