Message197291
[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? |
|
Date |
User |
Action |
Args |
2013-09-08 17:30:36 | tim.peters | set | recipients:
+ tim.peters, jcea, csernazs, ncoghlan, pitrou, grahamd, neologix, python-dev, bkabrda, koobs, Tamas.K |
2013-09-08 17:30:36 | tim.peters | set | messageid: <1378661436.56.0.375027467336.issue18808@psf.upfronthosting.co.za> |
2013-09-08 17:30:36 | tim.peters | link | issue18808 messages |
2013-09-08 17:30:36 | tim.peters | create | |
|