[issue31863] Inconsistent returncode/exitcode for terminated child processes on Windows

[Eryk Sun]

Eryk Sun <eryksun at gmail.com> added the comment:

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.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31863>
_______________________________________