[issue25960] Popen.wait() hangs when called from a signal handler when os.waitpid() does not

Mike Frysinger report at bugs.python.org
Mon Feb 24 19:13:37 EST 2020


Mike Frysinger <vapier at users.sourceforge.net> added the comment:

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.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25960>
_______________________________________


More information about the Python-bugs-list mailing list