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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4