@izbyshev: Would you mind to review this change? Are you fine with documentating the limitation rather trying to fixing it?

@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.

Personally, I'd wait at least until we're done with bpo-35823.

Ok, let's do that ;-)

@izbyshev: More generally, I like how things are going one. Slowly, we listed more and more bugs and corner cases, and we had to experiment posix_spawn() and dig into the code (well, in practice that part mostly done by you @izbyshev :-D) to be able to get this list. I'm fine with dropping posix_spawn() from subprocess if we can successfully use vfork in _posixsubprocess. I'm open to different options, as soon as subprocess runs faster :-)

Four months later, I see no activity on the idea of modiying _posixsubprocess to use vfork(), so I updated this change and I propose to merge it.

@eamanu and @gpshead: Would you mind to review my update PR?