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:
Tim Peters 2006-07-25 04:07:22 +00:00
parent 4d16b915aa
commit 0c4a3b330d
1 changed files with 4 additions and 3 deletions

View File

@ -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()