<https://docs.python.org/3.11/library/multiprocessing.html#multiprocessing.Process.exitcode> describes exitcode as

"The child’s exit code. This will be None if the process has not yet terminated. A negative value -N indicates that the child was terminated by signal N."

and similarly in earlier documentation versions.

This does not describe what the exit code will be under normal circumstances, or if the child abends by raising a Python exception.

By examination of BaseProcess._bootstrap() it can be determined that the current behaviour appears to be:

* even if your subclass overrides the run() method, whatever this method returns is ignored (and in particular the return value has no effect on the child's exit code);

* if the run() method returns normally, the child's exit code will be 0;

* if the run() method raises SystemExit (or, I guess, calls sys.exit()) with an integer exit status, that exit status will be propagated to the child's exit code;

* if the run() method raises any other exception, the exception traceback will be printed to stderr and the child's exit code will be 1.


However I did not see a way to figure these details out from the documentation, and it is unclear whether all these details are supported behaviours.

Ping -- This issue has an associated PR that expands the multiprocessing.Process.exitcode documentation to cover normal, sys.exit(), and exception-raised termination of the child process.

    https://github.com/python/cpython/pull/30142

The PR has been available for a month but has not received any review comments.

New changeset 3852269b91fcc8ee668cd876b3669eba6da5b1ac by John Marshall in branch 'main':
bpo-45554: Document multiprocessing.Process.exitcode values (GH-30142)
https://github.com/python/cpython/commit/3852269b91fcc8ee668cd876b3669eba6da5b1ac

New changeset 4449a1694a0fd2c63fcef5eb7d0ad1d7dfbb6077 by Miss Islington (bot) in branch '3.10':
bpo-45554: Document multiprocessing.Process.exitcode values (GH-30142)
https://github.com/python/cpython/commit/4449a1694a0fd2c63fcef5eb7d0ad1d7dfbb6077

New changeset 0be4760d85399a308421d9229b5d7f1b4ec718a2 by Miss Islington (bot) in branch '3.9':
[3.9] bpo-45554: Document multiprocessing.Process.exitcode values (GH-30142) (GH-30675)
https://github.com/python/cpython/commit/0be4760d85399a308421d9229b5d7f1b4ec718a2

PR 30142 is sufficient for Unix, but it's missing a bit for Windows.

In Windows, the C runtime library maps the console event for Ctrl+Break to SIGBREAK. The default handler for SIGBREAK exits with 0xC000013A (i.e. STATUS_CONTROL_C_EXIT). This value is unrelated to the value of signal.SIGBREAK (21) or signal.SIGINT (2).

To forcefully terminate a process, Windows taskkill and Task Manager, and pretty much all utilities that can kill a process, call TerminateProcess() with 1 as the exit status. There's no way to know that this is a forced termination as opposed to an unhandled error.

The internal terminate() method in Windows uses 0x10000 as the real exit status of the process, but the internal wait() method maps this to -signal.SIGTERM (-15). Thus the case of calling Process.terminate(), and only this case, is faked in Windows to look like the process was killed by a signal.