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 kristjan.jonsson
Recipients csernazs, jyasskin, kristjan.jonsson, neologix, pitrou
Date 2012-04-10.10:05:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
We shouldn't be testing implementation details.  The Condition variables are canonically prone to "spurious wakeups" and "stolen wakeups".  The fact that the current implementation doesn't have them shouldn't place that burden on future implementations of threading.Condition on this platform.
From the docs: "Note: Condition variables can be, depending on the implementation, subject to both spurious wakeups (when wait() returns without a notify() call) and stolen wakeups (when another thread acquires the lock before the awoken thread.) For this reason, it is always necessary to verify the state the thread is waiting for when wait() returns and optionally repeat the call as often as necessary."

2) You would build a lock yourself if you wanted exact control over its behaviour.  In this case, we are just doing what threading.Lock() does, but it could be more complicated.  At any rate, it proves a useful toy usage of a condition variable in the context of making sure that it works properly as part of the unit tests.

I could leave the original test in place and just add the new ones, but the old test is at least provably a subject to a race condition as per the original issue.
Date User Action Args
2012-04-10 10:05:21kristjan.jonssonsetrecipients: + kristjan.jonsson, csernazs, pitrou, jyasskin, neologix
2012-04-10 10:05:21kristjan.jonssonsetmessageid: <>
2012-04-10 10:05:20kristjan.jonssonlinkissue8799 messages
2012-04-10 10:05:20kristjan.jonssoncreate