]> git.ipfire.org Git - thirdparty/Python/cpython.git/commit
[3.13] gh-87512: Fix `subprocess` using `timeout=` on Windows blocking with a large...
authorMiss Islington (bot) <31488909+miss-islington@users.noreply.github.com>
Sat, 29 Nov 2025 07:22:46 +0000 (08:22 +0100)
committerGitHub <noreply@github.com>
Sat, 29 Nov 2025 07:22:46 +0000 (07:22 +0000)
commit12471131a72341e9eebbf58e95aa4dbfe159efbe
tree42bc1758b4aec35a36e22b15464f82661a5be769
parentc4df097c41477c76821babc406f357804c9b998d
[3.13] gh-87512: Fix `subprocess` using `timeout=` on Windows blocking with a large `input=` (GH-142058) (#142069)

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.
(cherry picked from commit 5b1862bdd8021b5295df95d730c2d2efa827fa88)

Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>
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]