Gregory P. Smith added the comment: I think the forkserver approach is a good idea. It is what a lot of users will choose.
forkserver won't work everywhere though so the fork+exec option is still desirable to have available. Threads can be started by non-python code (extension modules, or the larger C/C++ program that is embedding the Python interpreter within it). In that context, by the time the multiprocessing module is can be too late to start a fork server and there is no easy way for Python code to determine if that is the case. The safest default would be fork+exec though we need to implement the fork+exec code as a C extension module or have it use subprocess (as I noted in the mb_fork_exec.patch review). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8713> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
