summaryrefslogtreecommitdiffstats
path: root/Lib/lib-tk
diff options
context:
space:
mode:
authorTim Peters <tim.peters@gmail.com>2004-08-20 03:27:12 (GMT)
committerTim Peters <tim.peters@gmail.com>2004-08-20 03:27:12 (GMT)
commit8d7626c23f89cfed31b04a05c9ec2fba7e0a7bf4 (patch)
treeadb123bb325a244a39d899ae90bb29eff07e1ad9 /Lib/lib-tk
parentafe5297b8a828c3a9d7e2b3404b6090b968c33e1 (diff)
downloadcpython-8d7626c23f89cfed31b04a05c9ec2fba7e0a7bf4.zip
cpython-8d7626c23f89cfed31b04a05c9ec2fba7e0a7bf4.tar.gz
cpython-8d7626c23f89cfed31b04a05c9ec2fba7e0a7bf4.tar.bz2
Stab at SF 1010777: test_queue fails occasionally
test_queue has failed occasionally for years, and there's more than one cause. The primary cause in the SF report appears to be that the test driver really needs entirely different code for thread tests that expect to raise exceptions than for thread tests that are testing non-exceptional blocking semantics. So gave them entirely different code, and added a ton of explanation. Another cause is that the blocking thread tests relied in several places on the difference between sleep(.1) and sleep(.2) being long enough for the trigger thread to do its stuff sot that the blocking thread could make progress. That's just not reliable on a loaded machine. Boosted the 0.2's to 10.0's instead, which should be long enough under any non-catastrophic system conditions. That doesn't make the test take longer to run, the 10.0 is just how long the blocking thread is *willing* to wait for the trigger thread to do something. But if the Queue module is plain broken, such tests will indeed take 10 seconds to fail now. For similar (heavy load) reasons, changed threaded-test termination to be willing to wait 10 seconds for the signal thread to end too.
Diffstat (limited to 'Lib/lib-tk')
0 files changed, 0 insertions, 0 deletions