homepage

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 Swen.Wenzel
Recipients Swen.Wenzel, Yuri.Bochkarev, anacrolix, isoschiz, kdlucas, ncoghlan, pitrou, rhettinger
Date 2015年01月05日.14:03:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1420466634.26.0.0351319948499.issue9634@psf.upfronthosting.co.za>
In-reply-to
Content
I have another use case.
The Docs use the producer-consumer pattern as a usage example.
I'm also using this pattern but apparently the consumers are not that stable during development phase.
So if one of your consumers dies during execution of its task, before it can say 'task done', then you will have a deadlock.
You could of course avoid this by adding a finally block which will claim the task is done even if there was some error or exception but then you will lie to the producer!
And suppose you only have one consumer and there are still tasks waiting (which is the case for my application), then you'll still have a deadlock since nobody is there to execute the remaining tasks.
This could be solved by putting the exception handling within the consumer's mainloop like this:
Consumer(Thread):
 def __init__(self, queue):
 self.queue = queue
 def run():
 while True:
 task = self.queue.get()
 try:
 # execute task
 except:
 # handle exception (hopefully) without reraising one
 finally:
 self.queue.task_done()
This way, however, the producer won't notice any issues unless the consumer's exception handler sets a flag or puts the exception into a collection that can be checked by the producer.
But even that is no solution if the consumer executes a task with an endless loop or runs into a deadlock itself.
I would propose to throw an exception if queue.Queue.join() returns because of a timeout since then you can investigate the cause within the exception handler and do not have to check for the consumer's status after each join(). But this is microoptimization so I would also be satisfied with the same solution as for threading.Thread.join().
History
Date User Action Args
2015年01月05日 14:03:54Swen.Wenzelsetrecipients: + Swen.Wenzel, rhettinger, ncoghlan, pitrou, anacrolix, kdlucas, isoschiz, Yuri.Bochkarev
2015年01月05日 14:03:54Swen.Wenzelsetmessageid: <1420466634.26.0.0351319948499.issue9634@psf.upfronthosting.co.za>
2015年01月05日 14:03:54Swen.Wenzellinkissue9634 messages
2015年01月05日 14:03:54Swen.Wenzelcreate

AltStyle によって変換されたページ (->オリジナル) /