diff options
author | Tim Peters <tim.peters@gmail.com> | 2004-08-20 03:27:12 (GMT) |
---|---|---|
committer | Tim Peters <tim.peters@gmail.com> | 2004-08-20 03:27:12 (GMT) |
commit | 8d7626c23f89cfed31b04a05c9ec2fba7e0a7bf4 (patch) | |
tree | adb123bb325a244a39d899ae90bb29eff07e1ad9 /Lib/lib-tk/tkFont.py | |
parent | afe5297b8a828c3a9d7e2b3404b6090b968c33e1 (diff) | |
download | cpython-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/tkFont.py')
0 files changed, 0 insertions, 0 deletions