-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
gh-91378: Allow subprocess pass-thru with stdout/stderr capture #32344
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
b4bdfa3
bpo-47222: avoid ResourceWarnings about unclosed files (GH-91378)
pprindeville 9e0464e
bpo-47222: Avoid .rstrip() where exact output is expected (GH-91378)
pprindeville 70e603a
bpo-47222: Refactor stdout/stderr pipe handler into function (GH-91378)
pprindeville becf1f6
bpo-47222: Add test coverage for user-specified read_callback (GH-91378)
pprindeville 7f1ef61
bpo-47222: Allow pass-thru with stdout/stderr capture (GH-91378)
pprindeville File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
3 changes: 3 additions & 0 deletions
3
Misc/NEWS.d/next/Library/2022-04-05-22-15-55.bpo-47222.I5CLHq.rst
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
In the :mod:`subprocess` :class:`Popen`, factor the read callback handler for the ``PIPE`` file descriptors into its own function. Also add class variables pointing to the *stdout* and *stderr* read handlers. Lastly, add constructor variable ``read_stdout_callback`` and ``read_stderr_callback`` to allow overriding the handler with a user-supplied function. | ||
|
||
Also add the method ``tee_pipe_to(handle)`` to this class, which indicates that output on the pipes should be copied to the parent's buffers, as well as being cloned onto the named *handle*. |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Windows uses threads for the stdout and stderr reading so that it can just do this single blocking unbounded blocking read(). Keeping this behavior when a read_callaback or tee is specified seems to defeat the purpose as it'll wait until the process has completed before calling the callback (tee'ing the output) all at once. That isn't what someone who has specified tee wants and probably isn't what someone who has specified their own read_callback wants. As there is little point in either of those if you don't get data asynchronously as it comes in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does one then handle a disparity of rates between how quickly one can read from
fh
and how quickly they can write tosys.stdout
? I don't see a simple solution, unless I've misunderstood what you're saying.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't expect any
tee
like process to handle this. The posix side of things in this code doesn't either, it reads up to 32k when the selector event says the pipe has data and calls the callback on that. if the callback blocks, the child process can thus also block on IO when one of its pipe buffers fills up.there's also the issue of threading, if a callback might be called from a different thread rather than in the thread calling Popen.communicate, that needs to be documented.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if that's a constraint of the original design that we're just uncovering? Is that really an issue to fix here, or just something to call out and having been exposed...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The original design consumes all pipe data as it comes in and buffers it as it is only available as a whole upon process exit when
communicate()
returns. The reason I bring this up here is that the tee and callback behavior would be inconsistent between Windows and posix such that the a read callback and tee wouldn't be very useful on Windows.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gpshead Do you want me to proceed with that change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gpshead I don't know how to proceed. It would seem that the functionality of this feature has additional contractual obligations on Windows that aren't implied anywhere else. Should I just limit the functionality of the baked-in "tee" functionality to non-Windows (i.e. POSIX) platforms instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've disabled the
tee
functionality for Windows.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This still leaves Windows behind, it won't make callbacks in real time as data comes in. It isn't about
tee
so much as it's about having a similar user experience and behavior on both platforms. We need to conditionally do bounded read()s in a loop on windows when a callback is set.From a user point of view "good enough" is likely be to call
fh.readline(2000)
in a loop in this situation. The things someone wants to see data from live are often text based so reading by line, if present, otherwise a limited buffer is roughly the same to non-blocking reads of everything available. something like this:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like we're bifurcating the behavior on Windows depending on whether the callback has been installed or not. Why not just have consistent and predictable behavior?