Gregory P. Smith added the comment:
I agree with Victor. When code launches a process with subprocess APIs, it is
expected that the subprocess module manages the process.
Calling os.waitpid directly instead of using subprocess's APIs breaks that
expectation.
Also, WNOWAIT and waitid() (not
STINNER Victor added the comment:
If you care about race conditions in send_signal(), I suggest you to write a PR
to use the newly added os.pidfd_open() in subprocess:
https://docs.python.org/dev/library/os.html#os.pidfd_open
--
___
Python tracker
Jack O'Connor added the comment:
Right, the example above is contrived to demonstrate the race and the crash.
In real life code, the good reason I know of to write code like this is to use
os.waidid(WNOWAIT) to solve the wait/kill race properly. This is what Duct has
been doing, and Nathanie
STINNER Victor added the comment:
The script fails with "ChildProcessError: [Errno 10] No child processes" on
line:
> os.waitpid(child.pid, 0)
The line before, you call child.kill() which sends SIGKILL signal to the
process. So it's likely that the process will complete (killed by SIGKILL)
New submission from Jack O'Connor :
In Python 3.9, Popen.send_signal() was changed to call Popen.poll() internally
before signaling. (Tracking bug: https://bugs.python.org/issue38630.) This is a
best-effort check for the famous kill/wait race condition. However, because
this can now reap an a