views:

384

answers:

3

Hello,

I have one thread that writes results into a Queue.

In another thread (GUI), I periodically (in the IDLE event) check if there are results in the queue, like this:

def queue_get_all(q):
    items = []
    while 1:
        try:
            items.append(q.get_nowait())
        except Empty, e:
            break
    return items

Is this a good way to do it ?

Edit:

I'm asking because sometimes the waiting thread gets stuck for a few seconds without taking out new results.

The "stuck" problem turned out to be because I was doing the processing in the idle event handler, without making sure that such events are actually generated by calling wx.WakeUpIdle, as is recommended.

+1  A: 

I see you are using get_nowait() which according to the documentation, "return[s] an item if one is immediately available, else raise the Empty exception"

Now, you happen to break out of the loop when an Empty exception is thrown. Thus, if there is no result immediately available in the queue, your function returns an empty items list.

Is there a reason why you are not using the get() method instead? It may be the case that the get_nowait() fails because the queue is servicing a put() request at that same moment.

fuentesjr
I am not using get() because I don't want to block the GUI. It's OK if the call thinks theres nothing in the Q just when a new item is being put in, because I call it periodically
Eli Bendersky
+3  A: 

If you're always pulling all available items off the queue, is there any real point in using a queue, rather than just a list with a lock? ie:

from __future__ import with_statement
import threading

class ItemStore(object):
    def __init__(self):
        self.lock = threading.Lock()
        self.items = []

    def add(self, item):
        with self.lock:
            self.items.append(item)

    def getAll(self):
        with self.lock:
            items, self.items = self.items, []
        return items

If you're also pulling them individually, and making use of the blocking behaviour for empty queues, then you should use Queue, but your use case looks much simpler, and might be better served by the above approach.

[Edit2] I'd missed the fact that you're polling the queue from an idle loop, and from your update, I see that the problem isn't related to contention, so the below approach isn't really relevant to your problem. I've left it in in case anyone finds a blocking variant of this useful:

For cases where you do want to block until you get at least one result, you can modify the above code to wait for data to become available through being signalled by the producer thread. Eg.

class ItemStore(object):
    def __init__(self):
        self.cond = threading.Condition()
        self.items = []

    def add(self, item):
        with self.cond:
            self.items.append(item)
            self.cond.notify() # Wake 1 thread waiting on cond (if any)

    def getAll(self, blocking=False):
        with self.cond:
            # If blocking is true, always return at least 1 item
            while blocking and len(self.items) == 0:
                self.cond.wait()
            items, self.items = self.items, []
        return items
Brian
+2  A: 

I'd be very suprised if the get_nowait() call caused the pause by not returning if the list was empty.

Could it be that you're posting a large number of (maybe big?) items between checks which means the receiving thread has a large amount of data to pull out of the Queue? You could try limiting the number you retrieve in one batch:

def queue_get_all(q):
    items = []
    maxItemsToRetreive = 10
    for numOfItemsRetrieved in range(0, maxItemsToRetreive)
        try:
            if numOfItemsRetrieved == maxItemsToRetreive:
                break
            items.append(q.get_nowait())
        except Empty, e:
            break
    return items

This would limit the receiving thread to pulling up to 10 items at a time.

Jon Cage
It could cause long waits if he's calling it in a while 1: busyloop. If so, the consumer would not only be reducing the producer's timeslice, but would also spend a lot of time holding the Queue's lock, potentially livelocking the producer. (This is more likely if he has multiple consumer threads.)
Brian
Good point Brian. I got the impression that eliben wasn't calling this all _that_ frequenctly, but I could be wrong - eliben?
Jon Cage
Oops, you're right - I missed the part about calling it in an idle event. That wouldn't be enough to cause such problems.
Brian