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. _______________________________________________ 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
