bpo-35537: Document posix_spawn() change in subprocess by vstinner · Pull Request #11668 · python/cpython

@vstinner I hope that problems with QEMU, WSL and any other Linux environments where vfork is emulated via fork will be avoided if bpo-35823 is accepted. If that happens, there will be no known platform that both (a) has the problem you describe and (b) is eligible for posix_spawn as currently implemented in subprocess. Therefore, this change will effectively be the statement that we're OK with using posix_spawn in the future on platforms that suffer from such problems. Or, to put it another way, that we're willing to take the risk if we can't reliably check whether such issues exist when we decide to use posix_spawn. Is that what you intend to do?

Personally, I'd wait at least until we're done with bpo-35823. If it's merged, I'd prefer not to merge a part about "very specific platforms" and wait until we encounter another such case. If it's rejected, I agree that we should document this issue. Also, we could add a parameter to subprocess.Popen() to allow users to force traditional fork()/exec() path to workaround such issues.