Antoine Pitrou added the comment: > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31308> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
