classification
Title: Hang in lib/test/test_threading.py
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.2, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: csernazs, jyasskin, krisvale, pitrou
Priority: normal Keywords: easy, patch

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) * (Python committer) 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:31csernazssetnosy: + csernazs
2010-05-24 12:11:45krisvalesetkeywords: patch, patch, easy

messages: + msg106360
2010-05-24 11:43:21pitrousetversions: + Python 3.2
nosy: + jyasskin, pitrou

messages: + msg106355

keywords: patch, patch, easy
2010-05-24 09:44:15krisvalecreate