[Python-Dev] Re: Useful thread project for 2.5?

[Phillip J. Eby]

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.