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

[Tim Peters]

[Greg Ward]
>> 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.

See the link in my original post to Florent's Zope deadlock debugger. 
Things like the above are easy enough to create _given_ a bit of C
code in the core to build on.

[Phillip J. Eby]
> Couldn't this just be done with traceback.print_stack(), given the
> _current_frames() facility?

Right.

> 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 don't know that it matters.  If you're debugging a deadlocked
thread, its stack isn't going to change.  If you're trying to find out
where unexpected time is getting swallowed, statements in the
offending loop(s) are still going to show up in the stack trace.

> 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().

sys.getcheckinterval() was added in Python 2.3.

> 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.

Huh. It didn't remind me of those at all <wink>.