Author vstinner
Recipients gregory.p.smith, izbyshev, koobs, nanjekyejoannah, pablogsal, serhiy.storchaka, vstinner
Date 2019-01-15.22:54:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1547592863.67.0.00962837973551.issue35537@roundup.psfhosted.org>
In-reply-to
Content
Gregory P. Smith:
"""
Thanks for all your research and reference links on this!  As a _posixsubprocess maintainer, I am not against either posix_spawn or vfork being used directly in the future when feasible.

A challenge, especially with platform specific vfork, is making sure we understand exactly which platforms it can work properly on and checking for those both at compile time _and_ runtime (running kernel version and potentially the runtime libc version?) so that we can only use it in situations we are sure it is supposed to behave as desired in.  My guiding philosophy: Be conservative on choosing when such a thing is safe to use.
"""

About "My guiding philosophy: Be conservative on choosing when such a thing is safe to use.", I modified my PR 11452 to only use posix_spawn() on a very small subset of platforms where we know that the implementation is safe. It's different than early implementations which tried to use it as soon as it's available.
History
Date User Action Args
2019-01-15 22:54:25vstinnersetrecipients: + vstinner, gregory.p.smith, serhiy.storchaka, koobs, izbyshev, pablogsal, nanjekyejoannah
2019-01-15 22:54:23vstinnersetmessageid: <1547592863.67.0.00962837973551.issue35537@roundup.psfhosted.org>
2019-01-15 22:54:23vstinnerlinkissue35537 messages
2019-01-15 22:54:23vstinnercreate