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.06:06:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
if threading.active_count() returns 1, then you know there's one thread, and you're it, so it's not racey, and a lock ins't needed.

thinking a bit more, what if the code just use a recursive lock ?  that would restore the single threaded status quo without overly complicating the code.

thinking a bit more, i think you're right that this is inherently racy, but not because using the APIs in async context isn't permissible.  if a signal is delivered after Popen.wait() finishes the OS waitpid call, but before it releases the lock, then the child state is not recoverable from the signal handler.

in our case, we're using the signal handler to kill the process, and we want to make sure it's exited, so being able to get the exact exit status is not important to us, just making sure we can detect when the process is gone.
Date User Action Args
2020-02-25 06:06:45vapiersetrecipients: + vapier, gregory.p.smith, chris.jerdonek
2020-02-25 06:06:45vapiersetmessageid: <>
2020-02-25 06:06:45vapierlinkissue25960 messages
2020-02-25 06:06:45vapiercreate