Ronald Oussoren ronaldousso...@mac.com added the comment:
Is this issue still valid? The last comment seems to indicate that the issue is
fixed and could be closed.
--
nosy: +ronaldoussoren
___
Python tracker rep...@bugs.python.org
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
Closing this as fixed.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10237
___
Antoine Pitrou pit...@free.fr added the comment:
I also get a failure here:
==
FAIL: test_default_timeout (test.test_threading.BarrierTests)
--
Traceback (most
Stephen Hansen me+pyt...@ixokai.io added the comment:
FWIW, my snow leopard slave isn't slow at all so I doubt there's a timeout
related to machine speed going on here, as its failing thus:
test test_threading failed -- Traceback (most recent call last):
File
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
Silly me, changing the default timeout invalidated the unittest for it.
Fixed in revision 86018
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10237
New submission from Antoine Pitrou pit...@free.fr:
A buildbot has shows occasional failures in the Barrier tests:
[299/349] test_threading
[39130 refs]
[39501 refs]
[39501 refs]
[39491 refs]
[39499 refs]
Unhandled exception in thread started by function task at 0x45e4df54
Traceback (most recent
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
This is a timeout issue, probably encountered on a slow machine.
Checked in revision 85964 increasing the default timeout to cater to slower
machines.
However, I also see that the timeout mechanism used by barrier isn't very
