At 08:23 PM 3/7/05 -0500, Greg Ward wrote:
On 06 March 2005, Fazal Majid said:
Since I started this, I might as well finish it. I do have some Python developer experience (hey, I even voted for comp.lang.python back when...) but not in the core interpreter itself.
What would be *really* spiffy is to provide a way for externally-triggered thread dumps. This is one of my top two Java features [1]. The way this works in Java is a bit awkward -- "kill -QUIT" the Java process and it writes a traceback for every running thread to stdout -- but it works. Something similar ought to be possible for Python, although optional (because Python apps can handle signals themselves, unlike Java apps).
It could be as simple as this: calling
sys.enablethreaddump(signal=signal.SIGQUIT)
from the program enables externally-triggered thread dumps via the specified signal.
Couldn't this just be done with traceback.print_stack(), given the _current_frames() facility? About the only real problem with it is that the other threads can keep running while you're trying to print the stack dumps. I suppose you could set the check interval really high and then restore it afterwards as a sneaky way of creating a critical section. Unfortunately, there's no getcheckinterval(). Which reminds me, btw, it would be nice while we're adding more execution control functions to have a way to get the current trace hook and profiling hook, not to mention ways to set them on non-current threads. You can do these things from C of course; I mean accessible as part of the Python API.