> PEP: XXX > Title: Trace and Profile Support for Threads > Author: Jeremy Hylton <jeremy@alum.mit.edu> Nice idea, Jeremy! I have some more worries to add to the compatibility section. It seems reasonable for a trace implementation to implement a state machine that assumes that events come in certain orders, e.g. CALL, LINE, LINE, ..., RAISE or RETURN, and it might assume without checking that all these apply to the same frame. Calls from multiple threads would confuse such a tracer! If we can limit ourselves to threads started with the higher-level (and recommended) threading module, we could provide a different mechanism: you give the threading module a "tracer factory function" which is invoked when a thread is started and passed to sys.settrace(). Since sys.settrace() manipulates per-thread state, this should work. Since the API is new, there is no compatibility problem. The API could be super simple: threading.settrace(factory) This would cause the following to be executed when a new thread is started: sys.settrace(factory(frame, "thread", thread)) (An end-thread event should probably also be passed to the factory.) By giving the factory the same signature as the regular trace function, it is still possible to use the same tracer function if it doesn't get confused by events from multiple threads, but it's also possible to implement something different. No C code would have to be written. What do you think? Or does the dependency on the threading module kill this idea? (Then we should think of adding this to the thread module instead. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
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