Richard Oudkerk added the comment: > You cannot associate several conditions to the *inner lock*, because you > don't have access to them (otherwise I wouldn't open this issue).
Condition.wait_for_any() would create a single inner lock and add it to the _waiters list for each of the condition variables. notify() and notify_all() would need to deal with the possibility that releasing the inner lock fails with ThreadError because it has already been unlocked. > You may not need to test for a predicate when using .wait() . Only when > you're > using .wait_for() > This is what I'm most interested in mimicking. (Ignoring timeouts) wait() should be used with the idiom while <expr>: cond.wait() This allows the woken thread to check whether it is really supposed to continue -- it sounds like you are not doing this. The only advantage of using wait() over wait_for() is that sometimes it avoids you having to create a named function or lambda function like in cond.wait_for(lambda: not (<expr>)) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18078> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com