RetroSearch Browse

Mon Aug 29 19:16:08 CEST 2011 · https://mail.python.org/pipermail/python-dev/2011-August/113293.html

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.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2011-August/113293.html below:

[Python-Dev] issue 6721 "Locks in python standard library should be sanitized on fork"