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 oesteban
Recipients Francis Bolduc, brianboonstra, cvrebert, dan.oreilly, davin, jnoller, oesteban, pitrou, sbt
Date 2018-11-12.22:57:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1542063472.24.0.788709270274.issue22393@psf.upfronthosting.co.za>
In-reply-to
Content
I tried to reuse as much as I could from the patch, but it didn't solve the issue at first.

I have changed the responsibility of identifying and prescribing a solution when a worker got killed. In the proposed patch, the thread handling results (i.e. tasks queued by one worker as done) was responsible. In the PR, the responsibility is reassigned to the thread handling workers (since, basically, one or more workers suddenly die).

The patch defined a new BROKEN state that was assigned to the results handler thread. I transferred this behavior to the worker handler thread. But, I'm guessing that the BROKEN state should be assigned to the Pool object instead, to be fully semantic. Although that would require passing the reference to the object around and complicate unnecessarily the implementation. Happy to reconsider though.

I added three tests, one that was present with the patch, a variation of it adding some wait before killing the worker, and the one that Francis Bolduc posted here (https://bugs.python.org/issue22393#msg294968).

Please let me know whether any conversation about this bug should take place in GitHub, with the PR instead of here.

Thanks a lot for the guidance, Antoine.
History
Date User Action Args
2018-11-12 22:57:52oestebansetrecipients: + oesteban, pitrou, jnoller, cvrebert, sbt, dan.oreilly, davin, brianboonstra, Francis Bolduc
2018-11-12 22:57:52oestebansetmessageid: <1542063472.24.0.788709270274.issue22393@psf.upfronthosting.co.za>
2018-11-12 22:57:52oestebanlinkissue22393 messages
2018-11-12 22:57:52oestebancreate