homepage

The documentation for multiprocessing.exitcode says:
"""
 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.
"""
This is true for the "fork" method, but not "forkserver" where a child terminated by a signal will get an exitcode of 255. This is because forkserver relies on the child writing its own exit code in a pipe, which obviously doesn't work if it was killed (255 is simply a fallback value).
See forkserver's Popen.poll():
 def poll(self, flag=os.WNOHANG):
 if self.returncode is None:
 from multiprocessing.connection import wait
 timeout = 0 if flag == os.WNOHANG else None
 if not wait([self.sentinel], timeout):
 return None
 try:
 self.returncode = forkserver.read_unsigned(self.sentinel)
 except (OSError, EOFError):
 # The process ended abnormally perhaps because of a signal
 self.returncode = 255
 return self.returncode

New changeset dfd5f34634f9c505945e9348b4b799544680a7cf by Antoine Pitrou in branch 'master':
Fix bpo-30589: improve Process.exitcode with forkserver (#1989)
https://github.com/python/cpython/commit/dfd5f34634f9c505945e9348b4b799544680a7cf

I've merged a fix for Python 3.7. Since the fix is a bit delicate, I don't want to risk regression by merging it into 3.6 and 3.5. Closing now.

In the end, I'm glad I added a stress test (test_many_processes) as part of this issue.
It helper uncover a serious reliability issues in CPython's delivery of signals (https://bugs.python.org/issue30703) and then triggered the discovery of a more minor bug in our setitimer() wrapper (https://bugs.python.org/issue30807).
Hopefully signal processing is more reliable in Python now!