[issue38630] subprocess.Popen.send_signal() should poll the process
Роман Донченко
report at bugs.python.org
Mon Dec 9 15:11:43 EST 2019
Роман Донченко <dpb at corrigendum.ru> added the comment:
> What you do is split 'wait' into two parts: first it waits for me process to become reapable without actually reaping it. On Linux you can do this with waitid+WNOWAIT. On kqueue platforms you can do it with kqueue.
> Then, you take a lock, and use it to atomically call waitpid/waitid to reap the process + update self.returncode to record that you've done so.
> In send_signal, we use the same lock to atomically check whether the process has been reaped, and then send the signal if it hasn't.
It's a good idea, but it would break the scenario where two threads call wait() concurrently. It would create this race condition:
1. Thread A reaps the process.
2. Thread B thinks the process is still running, so it calls waitid+WNOHANG on a stale PID, with unpredictable results.
3. Thread A sets self.returncode.
What is needed here is a reader-writer lock. subprocess.wait would work like this (pseudocode):
with lock taken for reading:
os.waitid(..., WNOHANG)
with lock taken for writing:
os.waitid(...)
self.returncode = ...
Whereas subprocess.send_signal would work like this:
with lock taken for reading:
os.kill(...)
Unfortunately, it doesn't seem like Python has reader-writer locks in the library...
----------
nosy: +SpecLad
_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________
More information about the Python-bugs-list
mailing list