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.

1 files changed, 4 insertions, 3 deletions

diff --git a/Lib/test/test_sys.py b/Lib/test/test_sys.py
index 9d4bbe7..f1f1524 100644
--- a/Lib/test/test_sys.py
+++ b/Lib/test/test_sys.py
@@ -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()