[Patches] [ python-Patches-1175933 ] threading.Condition.wait() return value indicates timeout

[SourceForge.net]

Patches item #1175933, was opened at 2005-04-03 15:09
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175933&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Blais (blais)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Condition.wait() return value indicates timeout

Initial Comment:
A condition variable returns in two cases: it was
notified by another thread, or it timed out (if a
timeout was specified).  See an example in the popular
Boost C++ library:

http://boost.org/doc/html/condition.html

This patch adds this capability to the Python
threading.Condition.wait() method, which used to return
nothing.  I added the relevant couple of lines to the
documentaion as well (see patch).

(An example is using a condition variable as a sentinel
for exiting a loop or a polling thread.  Using the
return value one can decide whether to exit the loop or
not.)


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2005-04-30 00:39

Message:
Logged In: YES 
user_id=31435

Sorry, I think this is a poor idea, and mdehoon's suggestion 
for turning a correct use of .wait() into a doubly buggy one 
illustrates why:  there's no guarantee that self._empty() will 
return false just because .wait() returns without timing out --
 .wait() returning just means that it may not be a waste of 
time to check for the desired condition.  "notifying" a condvar 
emphatically does not mean that the desired condition holds, 
and any number of other threads can run for any amount of 
time between the times a condvar is notified and some wait()
er wakes up (so even if the desired condition does hold at the 
time notify() is called, it may not anymore by the time a wait()
er wakes).

The check should always be done when .wait() doesn't time 
out, and even if .wait() does time out, self._empty() may 
return false anyway.

Note too that .wait()'s caller holds the associated mutex 
regardless of whether return is due to timeout or notify, and 
the caller needs to release it again in either case.  Creating a 
distinction based on return value creates a new opportunity to 
screw up that part too.

I don't understand this:

> An example is using a condition variable as a sentinel
> for exiting a loop or a polling thread. Using the
> return value one can decide whether to exit the loop or
> not.)

To the extent that I might understand it, it sounds like a 
condvar is gross overkill, and that you'd want something 
simpler (perhaps an Event) in those cases.  But I can't flesh 
out the code you have in mind there.

----------------------------------------------------------------------

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-04-29 02:59

Message:
Logged In: YES 
user_id=488897

This looks like a good idea to me. It will help to clean up
the "get" method in Queue.py, which now has:

                while self._empty():
                    remaining = endtime - _time()
                    if remaining <= 0.0:
                        raise Empty
                    self.not_empty.wait(remaining)

Here, self.not_empty is an object of the class
threading.Condition. It seems odd that first we wait for
self.not_empty.wait to return, and then have to check
self._empty(), even though self.not_empty.wait could have
told us directly if it was notified or it timed out.

I'll write a message to python-dev in support of this patch
(I'm a mere patch reviewer, not an official Python developer).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175933&group_id=5470