Message190227
> 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>)) |
|
Date |
User |
Action |
Args |
2013-05-28 17:15:20 | sbt | set | recipients:
+ sbt, pitrou, neologix, JBernardo |
2013-05-28 17:15:20 | sbt | set | messageid: <1369761320.86.0.487688212845.issue18078@psf.upfronthosting.co.za> |
2013-05-28 17:15:20 | sbt | link | issue18078 messages |
2013-05-28 17:15:20 | sbt | create | |
|