-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Process: Avoid deadlock when standard streams are not redirected to files #4173
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
Comments
I don't remember why exactly we use Did you test does redirecting |
Yes, we are currently using stdout/err redirecting to a file as a workaround and it is working without issues. |
Good to know that redirecting to files works. It would still be good to investigate could we use Unfortunately I'm super busy and don't have time to look at this in the near future. I leave this issue open in case someone else is interested to look at it. |
Popen.communicate()
, not Popen.wait()
when stdout or stderr is a PIPE to avoid deadlocks
Popen.communicate()
, not Popen.wait()
when stdout or stderr is a PIPE to avoid deadlocksPopen.communicate()
, not Popen.wait()
, when stdout or stderr is PIPE to avoid deadlocks
PR #5302 implements this. |
this is also related to this issue.: #5345 |
Popen.communicate()
, not Popen.wait()
, when stdout or stderr is PIPE to avoid deadlocks
I fixed this in f2f2f99. The fix is based on PR #5302 by @franzhaas, but contains some cleanup, doc updates, and fix for handling closed stdout/stderr PIPEs. Big thanks for the PR! |
Docs were slightly outdated after handling outputs was enhanced in #4173.
One of our test cases started to hang after switching from Run And Return Rc And Output-keyword to a Run Process-keyword. We debugged the issue and noticed that one of the threads of our test application was stuck in fflush(). Issue is caused by the usage of Popen.wait() + read in Process-library. There is a note about this in a python subprocess-documentation:
"This will deadlock when using stdout=PIPE or stderr=PIPE and the child process generates enough output to a pipe such that it blocks waiting for the OS pipe buffer to accept more data. Use Popen.communicate() when using pipes to avoid that."
https://docs.python.org/3/library/subprocess.html#subprocess.Popen.wait
As stated by the note above, this happens only when pipes are used, and can be avoided by writing stdout/stderr to a file. I verified that indeed using Popen.communicate() instead of Popen.wait() fixes the problem.
Noticed the issue with RF 3.1.1 but tested that the issue is still there in version 4.1.3.
The text was updated successfully, but these errors were encountered: