Author vstinner
Recipients gregory.p.smith, izbyshev, nanjekyejoannah, pablogsal, pitrou, serhiy.storchaka, vstinner
Date 2018-12-20.16:35:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1545323743.97.0.788709270274.issue35537@psf.upfronthosting.co.za>
In-reply-to
Content
> Are you going to do experiments? If not, I can try to do some in early January.

I'm only interested to use posix_spawn(). If you want to experiment vfork() in _posixsubprocess: please go ahead!


> I've studied that, and that's what I referred to as "quality-of-implementation" problem. After glibc devs removed heap allocations and tweaked some other things, they could use vfork() in all cases. "musl" libc never had those problems and used vfork() from the beginning.

_posixsubprocess shouldn't allocate memory on the heap *after* fork(), only before. If it does, it's a bug. Last time I checked _posixsubprocess, it looked to be written properly.

But the subprocess module has the crazy 'preexec_fn' option which makes things complicated... Maybe we should deprecate (and then remove) it, it's dangerous and it can be avoided in many cases. Using a launcher program is safer than relying on preexec_fn. In OpenStack, I reimplemented prlimit in pure Python. It's an example of launcher to set an option in the child process:
https://github.com/openstack/oslo.concurrency/blob/master/oslo_concurrency/prlimit.py
History
Date User Action Args
2018-12-20 16:35:44vstinnersetrecipients: + vstinner, gregory.p.smith, pitrou, serhiy.storchaka, izbyshev, pablogsal, nanjekyejoannah
2018-12-20 16:35:43vstinnersetmessageid: <1545323743.97.0.788709270274.issue35537@psf.upfronthosting.co.za>
2018-12-20 16:35:43vstinnerlinkissue35537 messages
2018-12-20 16:35:42vstinnercreate