RetroSearch Browse

Fri Aug 26 17:53:36 CEST 2011 · https://mail.python.org/pipermail/python-dev/2011-August/113128.html

Hi,

> I think that "deprecating" the use of threads w/ multiprocessing - or
> at least crippling it is the wrong answer. Multiprocessing needs the
> helper threads it uses internally to manage queues, etc. Removing that
> ability would require a near-total rewrite, which is just a
> non-starter.

I agree that this wouldn't actually benefit anyone.
Besides, I don't think it's even possible to avoid threads in
multiprocessing, given the various constraints. We would have to force
the user to run their main thread in an event loop, and that would be
twisted (tm).

> I would focus on the atfork() patch more directly, ignoring
> multiprocessing in the discussion, and focusing on the merits of gps'
> initial proposal and patch.

I think this could also be combined with Charles-François' patch.

Regards

Antoine.

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

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

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