Message178314
| 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:41 | gregory.p.smith | set | recipients:
+ 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:41 | gregory.p.smith | set | messageid: <1356638921.63.0.168473635992.issue8713@psf.upfronthosting.co.za> |
| 2012年12月27日 20:08:41 | gregory.p.smith | link | issue8713 messages |
| 2012年12月27日 20:08:41 | gregory.p.smith | create |
|