[issue13841] multiprocessing should use sys.exit() where possible

Changes by Richard Oudkerk : -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker ___

[issue13841] multiprocessing should use sys.exit() where possible

Roundup Robot added the comment: New changeset d31e83497c5a by Richard Oudkerk in branch 'default': Issue #13841: Make child processes exit using sys.exit() on Windows http://hg.python.org/cpython/rev/d31e83497c5a -- nosy: +python-dev ___ Python trac

[issue13841] multiprocessing should use sys.exit() where possible

Richard Oudkerk added the comment: The trivial patch of replacing exit() by sys.exit() caused manager processes to be terminated after a short timeout. (It is inconvenient that in Python there is no way for a non-main thread to request immediate shutdown of the process.) This new patch makes

[issue13841] multiprocessing should use sys.exit() where possible

sbt added the comment: I think the patch makes multiprocessing.util._exit_function() run twice in non-main processes because it is registered with atexit, and is also called in Process._bootstrap(). _exit_function() does the following: * terminate active daemon processes; * join active no

[issue13841] multiprocessing should use sys.exit() where possible

Charles-François Natali added the comment: Here's a trivial patch. I run the testsuite on one of the Windows buildbots, and there was one failure, in test_concurrent_futures: """ == FAIL: test_interpreter_shutdown (test.test_

[issue13841] multiprocessing should use sys.exit() where possible

Changes by Terry J. Reedy : -- stage: -> test needed versions: -Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue13841] multiprocessing should use sys.exit() where possible

Charles-François Natali added the comment: > * atexit callbacks are NOT run (although multiprocessing.util._exit_function > IS run), It may be a good thing after a fork() (e.g. you don't want to remove the same file twice), but it most definitely looks wrong for a new interpreter process (à la

[issue13841] multiprocessing should use sys.exit() where possible

Jon Brandvein added the comment: Good point. I don't think those particular behaviors are documented, so I'm not sure whether we need to worry about breaking them. -- ___ Python tracker __

[issue13841] multiprocessing should use sys.exit() where possible

sbt added the comment: Currently, on both Windows and Unix, when the main thread of a child process exits: * atexit callbacks are NOT run (although multiprocessing.util._exit_function IS run), * the main thread does NOT wait for non-daemonic background threads. A simple replacement of ExitP

[issue13841] multiprocessing should use sys.exit() where possible

New submission from Jon Brandvein : Currently the multiprocessing library calls a hard exit function (os._exit under unix, ExitProcess under Windows) to terminate the child process. Under unix, this is necessary because the child is forked without exec-ing. Calling sys.exit() would make it pos