Created on 2010-05-24 09:44 by krisvale, last changed 2010-06-29 08:44 by csernazs.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| locktest.patch | krisvale, 2010-05-24 09:44 | review | ||
| Messages (3) | |||
|---|---|---|---|
| msg106349 - (view) | Author: Kristján Valur Jónsson (krisvale) * | Date: 2010-05-24 09:44 | |
The tests for the ConditionVariable a fragile. On a slow computer, or when running a DEBUG build, the main thread can issue a condition.notify() call, even though the worker threads have not settled in on a wait() call. This causes the test to stall. The provided patch "fixes" this by adding a short _wait() before the notify. |
|||
| msg106355 - (view) | Author: Antoine Pitrou (pitrou) *  |
Date: 2010-05-24 11:43 | |
Strange, I have never noticed this (even on the buildbots). |
|||
| msg106360 - (view) | Author: Kristján Valur Jónsson (krisvale) * | Date: 2010-05-24 12:11 | |
Well, I saw this occasionally on my dual core laptop when working on the RWLock. A notify() before a target does a wait() is ineffective and it would wait indefinitely after the notify(5) call. This isn't a "proper" fix (I had another, more complex, where we would keep a counter for the number of successful "waiters" and wait for that to reach the target value) but it is in the spirit of many of these tests, where we rely on _wait() to be sufficient to reach a certain state. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2010-06-29 08:44:31 | csernazs | set | nosy:
+ csernazs |
| 2010-05-24 12:11:45 | krisvale | set | keywords:
patch, patch, easy messages: + msg106360 |
| 2010-05-24 11:43:21 | pitrou | set | versions:
+ Python 3.2 nosy: + jyasskin, pitrou messages: + msg106355 keywords: patch, patch, easy |
| 2010-05-24 09:44:15 | krisvale | create | |