[issue31814] subprocess_fork_exec more stable with vfork

2018-04-04 Thread Gregory P. Smith
Change by Gregory P. Smith : -- assignee: -> gregory.p.smith resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker

[issue31814] subprocess_fork_exec more stable with vfork

2018-04-04 Thread Gregory P. Smith
Gregory P. Smith added the comment: A raw os.posix_spawn() API has been added to 3.7. vfork() would likely all sorts of other problems. It is extremely complicated and implementations have bugs. CERT says never to use it.

[issue31814] subprocess_fork_exec more stable with vfork

2018-04-02 Thread Łukasz Langa
Change by Łukasz Langa : -- versions: -Python 3.7 ___ Python tracker ___ ___

[issue31814] subprocess_fork_exec more stable with vfork

2018-04-02 Thread Łukasz Langa
Łukasz Langa added the comment: Greg, the flip side is that now any Python user is at the mercy of third-party library providers to do the right thing in terms of pthread_atfork(). It won't always be feasible for the user to influence the third party to fix the problem.

[issue31814] subprocess_fork_exec more stable with vfork

2017-10-20 Thread Gregory P. Smith
Change by Gregory P. Smith : -- components: +Extension Modules -Interpreter Core type: behavior -> enhancement ___ Python tracker ___

[issue31814] subprocess_fork_exec more stable with vfork

2017-10-20 Thread Gregory P. Smith
Gregory P. Smith added the comment: Using new syscalls for _posixsubprocess.c would be a feature so it would be limited to 3.7+ if done at all. My gut feeling is that the real bug is in *any* library code that uses pthread_atfork() in a non thread safe manner. That code is

[issue31814] subprocess_fork_exec more stable with vfork

2017-10-20 Thread Ned Deily
Change by Ned Deily : -- nosy: +gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list

[issue31814] subprocess_fork_exec more stable with vfork

2017-10-20 Thread Albert Zeyer
Albert Zeyer added the comment: Here is some more background for a case where this occurs: https://stackoverflow.com/questions/46849566/multi-threaded-openblas-and-spawning-subprocesses My proposal here would fix this. -- ___

[issue31814] subprocess_fork_exec more stable with vfork

2017-10-19 Thread Albert Zeyer
Albert Zeyer added the comment: This is a related issue, although with different argumentation: https://bugs.python.org/issue20104 -- ___ Python tracker

[issue31814] subprocess_fork_exec more stable with vfork

2017-10-18 Thread Albert Zeyer
New submission from Albert Zeyer : subprocess_fork_exec currently calls fork(). I propose to use vfork() or posix_spawn() or syscall(SYS_clone, SIGCHLD, 0) instead if possible and if there is no preexec_fn. The difference would be that fork() will call any atfork