[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