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