GeezerVison

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA).

Unfortunately we couldn't find an account corresponding to your GitHub username on bugs.python.org (b.p.o) to verify you have signed the CLA (this might be simply due to a missing "GitHub Name" entry in your b.p.o account settings). This is necessary for legal reasons before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

Thanks again to your contribution and we look forward to looking at it!

Thanks for posting this. Before going forward, you'll need to do two things:

• sign the CLA as explained by the bot above
• add a NEWS file which you can generate using the blurb utility.

I'll also post some comments on your PR.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

I have made the requested changes; please review again

Thanks for making the requested changes!

@pitrou: please review the changes made to this pull request.

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

Thanks for making the requested changes!

@pitrou: please review the changes made to this pull request.

@poxthegreat thanks for the updates! Actually we need to test both cases: the one where stdout/stderr are mutated before launching the process, and the one where they are mutated inside the child process. I'll produce a new PR with the required changes.

I'm closing this PR in favor of PR #6079.