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.
Moved the code for _PyThread_CurrentFrames() up, so it's no longer
in a huge "#ifdef WITH_THREAD" block (I didn't realize it /was/ in
one).
Changed test_sys's test_current_frames() so it passes with or without
thread supported compiled in.
Note that test_sys fails when Python is compiled without threads,
but for an unrelated reason (the old test_exit() fails with an
indirect ImportError on the `thread` module). There are also
other unrelated compilation failures without threads, in extension
modules (like ctypes); at least the core compiles again.
Do we really support --without-threads? If so, there are several
problems remaining.
and test_support.run_classtests() into run_unittest()
and use it wherever possible.
Also don't use "from test.test_support import ...", but
"from test import test_support" in a few spots.
From SF patch #662807.
rarely needed, but can sometimes be useful to release objects
referenced by the traceback held in sys.exc_info()[2]. (SF patch
#693195.) Thanks to Kevin Jacobs!
module. This increases code coverage of Python/sysmodule.c
from 68% to 77% (on Linux).
The script doesn't exercise the error branch that handles an evil
or lost sys.excepthook in Python/pythonrun.c::PyErr_PrintEx().
Also this script might not work on Jython in its current form.
From SF patch #662807.
Tim Peters
Martin v. Löwis
Walter Dörwald
Michael W. Hudson
Guido van Rossum
Neal Norwitz