➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author carljm
Recipients carljm, corona10, dino.viehland, eelizondo, gregory.p.smith, nascheme, pablogsal, pitrou, shihai1991, steve.dower, tim.peters, vstinner
Date 2020-04-15.21:50:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1586987453.24.0.187620498143.issue40255@roundup.psfhosted.org>
In-reply-to
Content 
> I would be interested to hear the answer to Antoine's question which is basically: why not using the multiprocessing fork server?

Concretely, because for a long time we have used the uWSGI application server and it manages forking worker processes (among other things), and AFAIK nobody has yet proposed trying to replace that with something built around the multiprocessing module. I'm actually not aware of any popular Python WSGI application server built on top of the multiprocessing module (but some may exist).

What problem do you have in mind that the fork server would solve? How is it related to this issue? I looked at the docs and don't see that it does anything to help sharing Python objects' memory between forked processes without CoW.
History
Date User Action Args
2020-04-15 21:50:53carljmsetrecipients: + carljm, tim.peters, nascheme, gregory.p.smith, pitrou, vstinner, dino.viehland, steve.dower, corona10, pablogsal, eelizondo, shihai1991
2020-04-15 21:50:53carljmsetmessageid: <1586987453.24.0.187620498143.issue40255@roundup.psfhosted.org>
2020-04-15 21:50:53carljmlinkissue40255 messages
2020-04-15 21:50:53carljmcreate