docs: document Windows stdio subprocess stdin handling (#3079)
This commit is contained in:
parent
03aaebd3aa
commit
e464f72c12
1 changed files with 59 additions and 0 deletions
|
|
@ -41,6 +41,30 @@ Nothing prints, and it doesn't return. It is waiting on stdin for a host to spea
|
|||
|
||||
That also means stdout **is the wire**. A stray `print()` corrupts the stream; the `logging` module writes to stderr and is the right tool. That story is in **[Logging](../handlers/logging.md)**.
|
||||
|
||||
On Windows, the same rule applies to child processes your tools start. A child
|
||||
that inherits the stdio server's stdin can block behind the server's protocol
|
||||
reader. If your tool starts a subprocess and you do not intend to feed it input,
|
||||
redirect the child's stdin:
|
||||
|
||||
```python
|
||||
import asyncio
|
||||
import subprocess
|
||||
import sys
|
||||
|
||||
|
||||
async def run_script() -> tuple[bytes, bytes]:
|
||||
process = await asyncio.create_subprocess_exec(
|
||||
sys.executable,
|
||||
"script.py",
|
||||
stdin=subprocess.DEVNULL,
|
||||
stdout=subprocess.PIPE,
|
||||
stderr=subprocess.PIPE,
|
||||
)
|
||||
return await process.communicate()
|
||||
```
|
||||
|
||||
The matching troubleshooting entry is **[My stdio tool hangs when it starts a subprocess on Windows](../troubleshooting.md#my-stdio-tool-hangs-when-it-starts-a-subprocess-on-windows)**.
|
||||
|
||||
### Try it
|
||||
|
||||
```console
|
||||
|
|
|
|||
Loading…
Reference in a new issue