]> git.ipfire.org Git - thirdparty/Python/cpython.git/commit
gh-87512: Fix `subprocess` using `timeout=` on Windows blocking with a large `input...
authorGregory P. Smith <68491+gpshead@users.noreply.github.com>
Sat, 29 Nov 2025 06:07:03 +0000 (22:07 -0800)
committerGitHub <noreply@github.com>
Sat, 29 Nov 2025 06:07:03 +0000 (22:07 -0800)
commit5b1862bdd8021b5295df95d730c2d2efa827fa88
treefd3036143d4e8d4ddc6c0b7c0aaa5ca858cc8e90
parent923056b2d41c4c28ad9163901053cd3824d775c5
gh-87512: Fix `subprocess` using `timeout=` on Windows blocking with a large `input=` (GH-142058)

On Windows, Popen._communicate() previously wrote to stdin synchronously, which could block indefinitely if the subprocess didn't consume input= quickly and the pipe buffer filled up. The timeout= parameter was only checked when joining the reader threads, not during the stdin write.

This change moves the Windows stdin writing to a background thread (similar to how stdout/stderr are read in threads), allowing the timeout to be properly enforced. If timeout expires, TimeoutExpired is raised promptly and the writer thread continues in the background. Subsequent calls to communicate() will join the existing writer thread.

Adds test_communicate_timeout_large_input to verify that TimeoutExpired is raised promptly when communicate() is called with large input and a timeout, even when the subprocess doesn't consume stdin quickly.

This test already passed on POSIX (where select() is used) but failed on Windows where the stdin write blocks without checking the timeout.

Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Lib/subprocess.py
Lib/test/test_subprocess.py
Misc/NEWS.d/next/Library/2025-11-29-03-02-45.gh-issue-87512.bn4xbm.rst [new file with mode: 0644]