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 SpecLad
Recipients SpecLad, giampaolo.rodola, njs, vstinner
Date 2019-12-09.20:11:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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:
    self.returncode = ...

Whereas subprocess.send_signal would work like this:

with lock taken for reading:

Unfortunately, it doesn't seem like Python has reader-writer locks in the library...
Date User Action Args
2019-12-09 20:11:43SpecLadsetrecipients: + SpecLad, vstinner, giampaolo.rodola, njs
2019-12-09 20:11:43SpecLadsetmessageid: <>
2019-12-09 20:11:43SpecLadlinkissue38630 messages
2019-12-09 20:11:42SpecLadcreate