Message190214
> BTW, I find .notify(N) not much useful, because the docs say it may wake
> more threads on a different implementation and also I can't never know
> whom am I waking.
The fact that more than N threads can wake up is not a problem if you are retesting an appropriate predicate as soon as your waiting threads awakes. (And if you are not retesting then you are abusing the condition variable.)
But it might be nice to be able to wait on multiple conditions at once, assuming they are associated with the same lock. Maybe we could have a static method
Condition.wait_for_any(cond_to_pred: dict, timeout=None) -> condition
where cond_to_pred is a mapping from condition variable to predicate function to test for. The return value would be the condition variable whose predicate is true (or None if there was a timeout). So then
cond.wait_for(pred)
would be equivalent to
Condition.wait_for_any({cond: pred}) is cond |
|
Date |
User |
Action |
Args |
2013-05-28 14:36:21 | sbt | set | recipients:
+ sbt, pitrou, neologix, JBernardo |
2013-05-28 14:36:21 | sbt | set | messageid: <1369751781.1.0.159429045713.issue18078@psf.upfronthosting.co.za> |
2013-05-28 14:36:21 | sbt | link | issue18078 messages |
2013-05-28 14:36:20 | sbt | create | |
|