This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vapier
Recipients chris.jerdonek, gregory.p.smith, vapier
Date 2020-02-25.00:13:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
to be clear, there is no Python or OS restriction that you're aware of for your earlier statement ?  you just want to make it into a new Popen restriction that didn't previously exist ?

we came across this bug as we upgraded our existing Python 2.7 codebase to Python 3.6.  so even if it's "been this way for a while" (which is to say, since the 3.4.1 release), at least some people are going to be coming across this for the first time as they migrate.

if the popen APIs aren't going to handle this correctly (check threading.active_count?), can we at least get a knob to disable it or class methods we can stub out ?  we never use threads, so having popen add support for a runtime mode we never utilize is kind of annoying.

for now i'm defining a custom subprocess.Popen class to break the lock, but it's kind of terrible to have to access _waitpid_lock outside of the subprocess module.
Date User Action Args
2020-02-25 00:13:37vapiersetrecipients: + vapier, gregory.p.smith, chris.jerdonek
2020-02-25 00:13:37vapiersetmessageid: <>
2020-02-25 00:13:37vapierlinkissue25960 messages
2020-02-25 00:13:37vapiercreate