Message332238
> 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 |
|
Date |
User |
Action |
Args |
2018-12-20 16:35:44 | vstinner | set | recipients:
+ vstinner, gregory.p.smith, pitrou, serhiy.storchaka, izbyshev, pablogsal, nanjekyejoannah |
2018-12-20 16:35:43 | vstinner | set | messageid: <1545323743.97.0.788709270274.issue35537@psf.upfronthosting.co.za> |
2018-12-20 16:35:43 | vstinner | link | issue35537 messages |
2018-12-20 16:35:42 | vstinner | create | |
|