FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

[3.14] gh-87512: Fix `subprocess` using `timeout=` on Windows blocking with a large `input=` (GH-142058) by miss-islington · Pull Request #142068 · python/cpython · GitHub

Repository navigation

[3.14] gh-87512: Fix subprocess using timeout= on Windows blocking with a large input= (GH-142058) - #142068

Merged
gpshead merged 2 commits into
python:3.14from
miss-islington:backport-5b1862b-3.14
Nov 29, 2025
Merged

gpshead merged 2 commits into
python:3.14from
miss-islington:backport-5b1862b-3.14

Conversation

miss-islington commented Nov 29, 2025 •
edited by bedevere-app Bot
Loading

Copy link
Copy Markdown
Contributor

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 5b1862b)

Co-authored-by: Gregory P. Smith 68491+gpshead@users.noreply.github.com
Co-authored-by: Claude Opus 4.5 noreply@anthropic.com

… with a large `input=` (pythonGH-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 5b1862b)

Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
gpshead merged commit c7f7411 into python:3.14 Nov 29, 2025
47 checks passed
miss-islington deleted the backport-5b1862b-3.14 branch January 2, 2026 16:49
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

topic-subprocess Subprocess issues. type-bug An unexpected behavior, bug, or error

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants


Back | FazBrowse Home | New Git URL