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 _______________________________________________ Patches mailing list [email protected] http://mail.python.org/mailman/listinfo/patches
