Message334404
Thanks for your _extremely detailed_ analysii of the (often sad) state of posix_spawn() on platforms in the world today.
My first reaction to this was "but then we'll be owning our own custom posix_spawn-like implementation as if we'll do better at it than every individual libc variant."
After reading this through and looking at your PR... I now consider that a good thing. =) We clearly can do better. vfork() is pretty simple and allows us to keep our semantics; providing benefits to existing users at no cost.
The plethora of libc bugs surrounding posix_spawn() seem likely to persist within various environments in the world for years to come. No sense in us waiting for that to settle.
As for your PR... a configure check for vfork, a news entry, and whatever other documentation updates seem appropriate.
With this in place we may want to make the _use_posix_spawn() logic in subprocess.py stricter? That could be its own followup PR. |
|
Date |
User |
Action |
Args |
2019-01-26 22:45:05 | gregory.p.smith | set | recipients:
+ gregory.p.smith, ronaldoussoren, vstinner, koobs, izbyshev, pablogsal |
2019-01-26 22:45:04 | gregory.p.smith | set | messageid: <1548542704.37.0.702132684995.issue35823@roundup.psfhosted.org> |
2019-01-26 22:45:04 | gregory.p.smith | link | issue35823 messages |
2019-01-26 22:45:04 | gregory.p.smith | create | |
|