This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients davin, pablogsal, pitrou, vstinner
Date 2019-07-08.08:27:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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:

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.
Date User Action Args
2019-07-08 08:27:56vstinnersetrecipients: + vstinner, pitrou, davin, pablogsal
2019-07-08 08:27:56vstinnersetmessageid: <>
2019-07-08 08:27:56vstinnerlinkissue37507 messages
2019-07-08 08:27:55vstinnercreate