[Python-Dev] draft PEP: Trace and Profile Support for Threads

[Guido van Rossum]

> 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/)