On Mon, Aug 29, 2011 at 1:16 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Mon, 29 Aug 2011 13:03:53 -0400 > Jesse Noller <jnol...@gmail.com> wrote: >> 2011/8/29 Charles-François Natali <neolo...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
