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 changesetdfd5f34634f9c505945e9348b4b799544680a7cf by Antoine Pitrou in branch 'master':Fixbpo-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!