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

[Jesse Noller]

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.