[Python-Dev] Re: Useful thread project for 2.5?
Phillip J. Eby
pje at telecommunity.com
Tue Mar 8 03:22:42 CET 2005
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 . 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
>from the program enables externally-triggered thread dumps via the
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.
More information about the Python-Dev