STINNER Victor <vstin...@redhat.com> added the comment:
> 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 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35537> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
