current_frames_with_threads(): There's actually no way
to guess /which/ line the spawned thread is in at the time sys._current_frames() is called: we know it finished enter_g.set(), but can't know whether the instruction counter has advanced to the following leave_g.wait(). The latter is overwhelming most likely, but not guaranteed, and I see that the "x86 Ubuntu dapper (icc) trunk" buildbot found it on the other line once. Changed the test so it passes in either case.
This commit is contained in:
parent
4d16b915aa
commit
0c4a3b330d
|
@ -274,8 +274,9 @@ class SysModuleTest(unittest.TestCase):
|
|||
t.start()
|
||||
entered_g.wait()
|
||||
|
||||
# At this point, t has finished its entered_g.set(), and is blocked
|
||||
# in its leave_g.wait().
|
||||
# At this point, t has finished its entered_g.set(), although it's
|
||||
# impossible to guess whether it's still on that line or has moved on
|
||||
# to its leave_g.wait().
|
||||
self.assertEqual(len(thread_info), 1)
|
||||
thread_id = thread_info[0]
|
||||
|
||||
|
@ -305,7 +306,7 @@ class SysModuleTest(unittest.TestCase):
|
|||
# And the next record must be for g456().
|
||||
filename, lineno, funcname, sourceline = stack[i+1]
|
||||
self.assertEqual(funcname, "g456")
|
||||
self.assertEqual(sourceline, "leave_g.wait()")
|
||||
self.assert_(sourceline in ["leave_g.wait()", "entered_g.set()"])
|
||||
|
||||
# Reap the spawned thread.
|
||||
leave_g.set()
|
||||
|
|
Loading…
Reference in New Issue