Fix deadlock when subprocess doesn't end with EOF #119
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.
This PR is for fixing the same problem what #104 have, but with another solution.
Problem
Deadlock occurred when we use
stdout.readline
to listen to thesubprocess
that doesn't end with EOF.I found that my Allzpark will freeze when closing the application that it just launched, IF Allzpark was launched from a Rez resolved context. And the freeze was because the
stdout.readline
keep sending empty lineb""
due to no EOF signal.So why there has no EOF emitted from subprocess when Allzpark is launched from a resolved context ? I haven't figure it out. :(
It seems like
cmd.exe
in subprocess is not able to send EOF, not sure.Here's a simple reproducible :
Nevertheless, I came up a solution that seems solid. 🤔
I have changed the
stderr
listening function to act likePopen.communicate()
, since I thinkstderr
doesn't need to be streamed.(Referenced from Python's
subprocess.py
)With that we can know when the subprocess is ended, and send our own EOF flag to the
stdout
listening thread to make it stop . Problem solved.