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 pitrou
Recipients davin, pitrou
Date 2017-09-11.09:18:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1505121506.45.0.782247541537.issue31308@psf.upfronthosting.co.za>
In-reply-to
Content
> 1) The implicit restart of the forkserver process seems in conflict with the zen of making things explicit.

Well, the forkserver process really is an implementation detail.  It already is started on-demand, so restarting it if needed sounded like a natural evolution.

Another example: in a multiprocessing Pool, if a worker process crashes, another will be restarted transparently (same in concurrent.futures.ProcessPoolExecutor, incidentally).

> 2) This would seem to make forkserver's behavior inconsistent with the behavior of things like the Manager which similarly creates its own process for managing resources but does not automatically restart that process if it should die or become unreachable.

That's possible.  I've never seen the Manager used in the wild.  Though if some fundamental difference justifies the inconsistency, the inconsistency is not really a problem.
History
Date User Action Args
2017-09-11 09:18:26pitrousetrecipients: + pitrou, davin
2017-09-11 09:18:26pitrousetmessageid: <1505121506.45.0.782247541537.issue31308@psf.upfronthosting.co.za>
2017-09-11 09:18:26pitroulinkissue31308 messages
2017-09-11 09:18:26pitroucreate