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 eryksun
Recipients Akos Kiss, eryksun, paul.moore, steve.dower, tim.golden, zach.ware
Date 2017-10-26.03:24:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1508988296.54.0.213398074469.issue31863@psf.upfronthosting.co.za>
In-reply-to
Content
Setting the exit code to the negative of a C signal value isn't generally meaningful in Windows. It seems multiprocessing doesn't have a significant use for this, other than getting a formatted exit code in the repr via its _exitcode_to_name dict. For example:

    p = multiprocessing.Process(target=time.sleep, args=(30,))
    p.start()
    p.terminate()

    >>> p
    <Process(Process-1, stopped[SIGTERM])>

This may mislead people into thinking incorrectly that Windows implements POSIX signals. Python uses the C runtime's emulation of the basic set of required signals. SIGSEGV, SIGFPE, and SIGILL are based on exceptions. SIGINT and SIGBREAK are based on console control events. SIGABRT and SIGTERM are for use with C `raise`. Additionally it implements os.kill via TerminateProcess and GenerateConsoleCntrlEvent. (The latter takes process group IDs, so it should have been used to implement os.killpg instead. Its use in os.kill is wrong and confusing.)

The normal exit code for a forced shutdown is 1, which you can confirm via Task Manager or `taskkill /F`. subprocess is correct here. I think multiprocessing should follow suit.
History
Date User Action Args
2017-10-26 03:24:56eryksunsetrecipients: + eryksun, paul.moore, tim.golden, zach.ware, steve.dower, Akos Kiss
2017-10-26 03:24:56eryksunsetmessageid: <1508988296.54.0.213398074469.issue31863@psf.upfronthosting.co.za>
2017-10-26 03:24:56eryksunlinkissue31863 messages
2017-10-26 03:24:55eryksuncreate