Logged In: YES 
user_id=10996

hi tim
thanks for the comments.

my use of a condition variable is exemplified in this
background thread, which computes something periodically,
and with which the main thread uses a condition variable to
communicate "pause" and "quit" states (there is
communication between only those two threads):

def background_thread( func, args, condvar, callbacks, delay ):
    """
    A background thread that computes something periodically.

    @func: function that computes something;
    @data: arguments for function that computes something;
    @condvar: a variable to indicate for the thread to stop
or pause.
              The variable is the 'pause' and 'quit' members
on the condvar.
    @callbacks: a list of functions to call when a new
result becomes available;
    """
    done = 0
    while not done:
        # compute something
        data = func(*args)
        
        # push the new data into the callbacks
        for cb in callbacks:
            cb(data)

        condvar.acquire()
        if condvar.pause:
            # this branch is used to pause the thread.
            condvar.wait()
        else:
            condvar.wait(delay)
        if condvar.quit:
            done = 1
        condvar.release()

instead of using the "quit" data member, i could instead use
the return value of the wait() call.  basically, exit the
loop when i've been signaled.

AFAIK this is a common usage pattern. i've seen it in a few
places.  do you see any problem with this usage?

not that it's really an argument, but i did see 3
independent implementations of wait() returning the
signaled/timeout boolean.

i think Event.wait() should also return the signaled/timeout
state.  it's information that should be returned to the
user, whether he uses it or not.  sure, people can screw up,
but if there is a legitimate case where it can be used, i
think it should be provided anyway.

also, you are correct about mdehoon's case, after returning
from wait(), one should check for the queue being empty or not.