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 rhettinger
Recipients kdlucas, pitrou, rhettinger
Date 2010-08-18.22:08:37
SpamBayes Score 1.5145663e-12
Marked as misclassified No
Message-id <1282169319.92.0.192233730471.issue9634@psf.upfronthosting.co.za>
In-reply-to
Content
One of the provided links is duplicate (repost from StackOverflow).  None of the links offer use cases which can be used to inform the design (i.e. is this the correct approach, should a timeout raise a RuntimeError like Condition.wait() does, should a timeout set a variable to indicate the timeout thread.join() does, should it just return with no indication of the reason for returning, should we just document the unfinished_tasks variable as read-only so that users can check it periodically, what are the common calling patterns, how does this fit in with the original design intent of letting worker threads finish all pending tasks before moving on to code that assumes that the work is done).

Without motivating use cases, it is hard to create a correct design or to know whether this should be done at all.  Unlike, thread.join() which has a long history in many contexts, the Queue.join/task_done API is newer; accordingly, the API should be grown somewhat cautiously.  I don't think we've established using queue.join() with a time-out is a best practice or preferred pattern to solving a given problem.  Instead, all we have is "it seems like a nice feature" which falls short of our usual standards.
History
Date User Action Args
2010-08-18 22:08:39rhettingersetrecipients: + rhettinger, pitrou, kdlucas
2010-08-18 22:08:39rhettingersetmessageid: <1282169319.92.0.192233730471.issue9634@psf.upfronthosting.co.za>
2010-08-18 22:08:38rhettingerlinkissue9634 messages
2010-08-18 22:08:37rhettingercreate