Author gregory.p.smith
Recipients asksol, brandon-rhodes, catalin.iacob, christian.heimes, cool-RR, dholth, gregory.p.smith, jnoller, mrmekon, ned.deily, neologix, numbernine, pitrou, rcoyner, sbt, vsekhar
Date 2012-12-27.20:08:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1356638921.63.0.168473635992.issue8713@psf.upfronthosting.co.za>
In-reply-to
Content
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).
History
Date User Action Args
2012-12-27 20:08:41gregory.p.smithsetrecipients: + gregory.p.smith, pitrou, christian.heimes, ned.deily, jnoller, rcoyner, asksol, cool-RR, dholth, brandon-rhodes, neologix, catalin.iacob, sbt, numbernine, vsekhar, mrmekon
2012-12-27 20:08:41gregory.p.smithsetmessageid: <1356638921.63.0.168473635992.issue8713@psf.upfronthosting.co.za>
2012-12-27 20:08:41gregory.p.smithlinkissue8713 messages
2012-12-27 20:08:41gregory.p.smithcreate