This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author sbt
Recipients JBernardo, neologix, pitrou, sbt
Date 2013-05-28.17:15:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1369761320.86.0.487688212845.issue18078@psf.upfronthosting.co.za>
In-reply-to
Content
> 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>))
History
Date User Action Args
2013-05-28 17:15:20sbtsetrecipients: + sbt, pitrou, neologix, JBernardo
2013-05-28 17:15:20sbtsetmessageid: <1369761320.86.0.487688212845.issue18078@psf.upfronthosting.co.za>
2013-05-28 17:15:20sbtlinkissue18078 messages
2013-05-28 17:15:20sbtcreate