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 Will Starms
Recipients Will Starms
Date 2017-10-17.19:31:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1508268690.14.0.213398074469.issue31782@psf.upfronthosting.co.za>
In-reply-to
Content
I've realized that my patch may not be ideal for general-purpose use, but it's a good start for a discussion on the proper way to implement a timeout.

My patch (which is based on a more involved modification to Pool) assumes that the joins after the first will complete within a timely fashion, which is not necessarily true. While this prevents leaving the pool in a half-joined state, it can still get stuck joining other components or at least take significantly longer than the requested timeout.

Assuming that joining an already-joined object is safe, or it can be wrapped in an if statement to check before rejoining, I feel the best solution would be to reduce the timeout as joins complete, either raising (much easier) or returning (like threading.thread, but makes an is_alive function more difficult) when the remaining timeout time hits zero.
History
Date User Action Args
2017-10-17 19:31:30Will Starmssetrecipients: + Will Starms
2017-10-17 19:31:30Will Starmssetmessageid: <1508268690.14.0.213398074469.issue31782@psf.upfronthosting.co.za>
2017-10-17 19:31:30Will Starmslinkissue31782 messages
2017-10-17 19:31:30Will Starmscreate