Condition.wait(0.5) doesn't respect it's timeout

Aahz aahz at
Sat Apr 18 17:28:42 CEST 2009

In article <8373c927-5ef2-4511-a439-25caa3fd6929 at>,
 <stephane.bisinger at> wrote:
>On Apr 18, 2:05=A0pm, a... at (Aahz) wrote:
>> Whether or not there's a bug, you likely will simplify your code if you
>> switch to using a Queue().
>I'm sorry, but I can't see how the queue would help me on this, since
>I only have 2 threads and the documentation esplicitly states that it
>helps with multiple threads. I have no items to put in the queue, my
>only concern is not to update the screen while I am changing the state
>of the contact list... Maybe there's something I didn't think of, but
>I'd need more details on your part if that is the case, because I
>really can't see the advantage of Queue in this situation...

Essentially, you use the Queue instead of the Condition.  When you want
to explicitly give up control in a thread, you get() on the Queue until
you get an object (with the optional timeout).  When the other thread is
done processing, it puts an object on the Queue (optionally doing a
get_nowait() at some point if it wants to make sure the Queue is cleaned

The critical advantage of using Queue is that you don't have to do the
acquire()/release() dance.

It's not so much that there's an advantage to using Queue in this one
specific case as the fact that you can use Queue for almost everything
you'd use other kinds of locking mechanisms, so you can reduce your
mental model for dealing with threading.
Aahz (aahz at           <*>

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur."  --Red Adair

More information about the Python-list mailing list