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 gregory.p.smith
Recipients gregory.p.smith, izbyshev, koobs, pablogsal, ronaldoussoren, vstinner
Date 2019-01-26.22:45:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1548542704.37.0.702132684995.issue35823@roundup.psfhosted.org>
In-reply-to
Content
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.
History
Date User Action Args
2019-01-26 22:45:05gregory.p.smithsetrecipients: + gregory.p.smith, ronaldoussoren, vstinner, koobs, izbyshev, pablogsal
2019-01-26 22:45:04gregory.p.smithsetmessageid: <1548542704.37.0.702132684995.issue35823@roundup.psfhosted.org>
2019-01-26 22:45:04gregory.p.smithlinkissue35823 messages
2019-01-26 22:45:04gregory.p.smithcreate