RetroSearch Browse

Mon Aug 29 19:42:02 CEST 2011 · https://mail.python.org/pipermail/python-dev/2011-August/113297.html

On Mon, Aug 29, 2011 at 1:22 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Le lundi 29 août 2011 à 13:23 -0400, Jesse Noller a écrit :
>>
>> 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.
>
> That sanitization is generally useful, though. For example if you want
> to use any I/O after a fork().

Oh! I don't disagree; I'm just against the removal of the ability to
mix multiprocessing and threads; which it does internally and others
do in every day code.

The "proposed" removal of that functionality - using the two together
- would leave users in the dust, and not needed if we patch
http://bugs.python.org/issue8713 - which at it's core is just an
addition flag. We could document the risk(s) of using the fork()
mechanism which has to remain the default for some time.

The point is, is that the solution to http://bugs.python.org/issue6721
should not be intertwined or cause a severe change in the
multiprocessing module (e.g. "rewriting from scratch"), etc. I'm not
arguing that both bugs should not be fixed.

jesse

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

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

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