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