← 输入框|bugs.python.org|刷新

➜

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.

作者 vstinner
收信人 barry, davin, josh.r, kapilt, lukasz.langa, miss-islington, ned.deily, pablogsal, pitrou, ronaldoussoren, tdsmith, vstinner
日期 2019-05-28.12:54:25
SpamBayes Score -1.0
Marked as misclassified 是
Message-id <1559048065.65.0.761320476128.issue33725@roundup.psfhosted.org>
In-reply-to
内容
As soon as the "fork" start method "just works" on Linux, I'm not sure why you want to use "spawn" by default on Linux.

I don't buy the "consistency" argument here. I'm not surprised that such "low level" module like multiprocessing behaves differently depending on the platform to get the "native" and most efficient way to spawn subprocesses.

In general, fork is bad, but it's also convenient and people rely on it to prepare data in a main process and then "duplicate" the process to inherit cooked data.

If someone wants to more away from fork by default, I would suggest to *first* enhance multiprocessing documentation to list issues caused by fork(), and maybe also described when fork is safe (never doesn't sound like a good answer, since so far, I'm not aware of tons of bug reports on Linux caused by fork :-)).
历史
日期 用户 动作 参数
2019-05-28 12:54:25vstinner修改recipients: + vstinner, barry, ronaldoussoren, pitrou, ned.deily, lukasz.langa, josh.r, tdsmith, davin, pablogsal, miss-islington, kapilt
2019-05-28 12:54:25vstinner修改messageid: <1559048065.65.0.761320476128.issue33725@roundup.psfhosted.org>
2019-05-28 12:54:25vstinner链接issue33725 messages
2019-05-28 12:54:25vstinner创建