> Side note: if you're modifying multiprocessing, asking for a review doesn't hurt ;-)

I only modified tests (I only added a *private* _stop() method which is only used by tests). When I touch the multiprocessing module directly, I wait for a review.

Right now, I'm embarrassed since my "multiprocessing tests call _run_finalizers()" change which was supposed to be simple and safe broke Refleak buildbots. I had to fix test_concurrent_futures to also explicitly closes the forkserver there:
https://github.com/python/cpython/pull/14643

I was quite surprised to discover that a test leaves a child process in background. IMHO tests should have zero side effects on following tests (at least a test file must clear all its resources when it completes).

Python finalization is *very* fragile (not reliable at all), so I prefer to release resources as soon as possible, to get errors reported. Multiprocessing tests failures are still common, and very likely caused by these small details like a server which isn't stopped properly (IMHO). Tests should get a fresh and reliable environment.

Maybe each test should ensure that the forkserver is stopped, but I chose the easy fix: only stop it once at (test file) exit. Start/stop the server in each test might make these tests even slower, whereas multiprocessing tests are almost part of the slowest tests.