bpo-31804: multiprocessing calls flush on sys.stdout at exit even if … by SlaushVunter · Pull Request #5492 · python/cpython (original) (raw)

I unified the unit tests. I recognized that the previous test did not test the spawn method correctly, because it set the sys.stdout and 'sys.stderr' before creating the child process and assumed that the child process will inherit this. Well not with the spawn method (on Windows at least). Maybe it worked so in the past? In particular the spawned process inherits the sys.__stderr__ and not the sys.stderr (I guess the same is true for stdout). You may check this with the following snippet:

import sys

import tempfile import multiprocessing

def print_stderr(): print('stderr:', sys.stderr.fileno(), sys.stderr) print('stderr:', sys.stderr.fileno(), sys.stderr)

if name == 'main': sys.stderr = tempfile.TemporaryFile('w')

p = multiprocessing.Process(target=print_stderr)
print('Parent:')
print_stderr()
print('Child:')
p.start()
p.join()

According to the documentation of multiprocessing:

The child process will only inherit those resources necessary to run the process objects run() method. In particular, unnecessary file descriptors and handles from the parent process will not be inherited.

I'm not so sure what unnecessary means but I have read that inheriting file descriptors can pose a security risk. Can this be the reason why custom outputs are not inherited? Or is this another bug?

Anyhow I replaced the similar test with my test because mine changes the stdout and stderr in the child processes so it does not depend on this, then extended my test with the Event check. Also the plain StringIO as a substitute for stdout and stderr is not good enough because it's flush method doesn't raise an exception if it was closed before.

I have made the requested changes; please review again