On Mon, Aug 29, 2011 at 1:16 PM, Antoine Pitrou <solipsis at pitrou.net> wrote: > On Mon, 29 Aug 2011 13:03:53 -0400 > Jesse Noller <jnoller at gmail.com> wrote: >> 2011/8/29 Charles-François Natali <neologix at free.fr>: >> >> +3 (agreed to Jesse, Antoine and Ask here). >> >> The http://bugs.python.org/issue8713 described "non-fork" implementation >> >> that always uses subprocesses rather than plain forked processes is the >> >> right way forward for multiprocessing. >> > >> > I see two drawbacks: >> > - it will be slower, since the interpreter startup time is >> > non-negligible (well, normally you shouldn't spawn a new process for >> > every item, but it should be noted) >> >> Yes; but spawning and forking are both slow to begin with - it's >> documented (I hope heavily enough) that you should spawn >> multiprocessing children early, and keep them around instead of >> constantly creating/destroying them. > > I think fork() is quite fast on modern systems (e.g. Linux). exec() is > certainly slow, though. > > The third drawback is that you are limited to picklable objects when > specifying the arguments for your child process. This can be annoying > if, for example, you wanted to pass an OS resource. > > Regards > > Antoine. Yes, it is annoying; but again - this makes it more consistent with the windows implementation. I'd rather that restriction than the "sanitization" of the ability to use threading and multiprocessing alongside one another.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4