Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[3.14] gh-87512: Fixsubprocess usingtimeout= on Windows blocking with a largeinput= (GH-142058)#142068

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
gpshead merged 2 commits intopython:3.14frommiss-islington:backport-5b1862b-3.14
Nov 29, 2025

Conversation

@miss-islington
Copy link
Contributor

@miss-islingtonmiss-islington commentedNov 29, 2025
edited by bedevere-appbot
Loading

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 commit5b1862b)

Co-authored-by: Gregory P. Smith68491+gpshead@users.noreply.github.com
Co-authored-by: Claude Opus 4.5noreply@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 commit5b1862b)Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
@gpsheadgpshead merged commitc7f7411 intopython:3.14Nov 29, 2025
47 checks passed
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@gpsheadgpsheadAwaiting requested review from gpsheadgpshead is a code owner

Assignees

No one assigned

Labels

topic-subprocessSubprocess issues.type-bugAn unexpected behavior, bug, or error

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@miss-islington@gpshead

[8]ページ先頭

©2009-2025 Movatter.jp