Tim Peters added the comment:
[Antoine]
> Oh, I also get the following sporadic failure
> which is triggered by slight change in semantics
> with Thread.join(timeout) :-)
> ======================================================================
> FAIL: test_various_ops (test.test_threading.ThreadTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/antoine/cpython/default/Lib/test/test_threading.py", line 113,
> in test_various_ops
> self.assertTrue(not t.is_alive())
> AssertionError: False is not true
Really! In context, the test does:
t.join()
self.assertTrue(not t.is_alive())
(BTW, that would be clearer as self.assertFalse(t.is_alive()) ;-) )
It was the intent that this continue to work - the only intended change in
Python-visible semantics had to do with join'ing with a timeout.
Without a timeout, I confess I don't see how this can fail. join() is
join(timeout=None), which does:
self._stopped.wait(timeout)
if self._stopped.is_set():
self._wait_for_tstate_lock(timeout is None)
which is
self._stopped.wait(None)
if self._stopped.is_set():
self._wait_for_tstate_lock(True)
which should be the same as
self._stopped.wait()
self._wait_for_tstate_lock(True)
after which _stopped should be set and _tstate_lock should be None. The
subsequent is_alive() should then return False, via its
return self._tstate_lock is not None
What's going wrong?
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
