[Python-Dev] Last chance! (original) (raw)

Nick Bastin nbastin at opnet.com
Mon Mar 29 13:36:21 EST 2004

On Mar 29, 2004, at 1:15 PM, Christian Tismer wrote:

Nick Bastin wrote:

On Mar 29, 2004, at 10:23 AM, Guido van Rossum wrote: Since the profiler is being invoked from the thread being profiled, how could it end up not being in the same thread?

(If I am missing something, I must be missing a lot about your design, so you might want to say quite a bit more on how it works.) ...previous reply to this email deleted after some testing... Nevermind, the specific situation that I was concerned about actually can't occur. I wasn't sure that I could make a guarantee that the profiler would be invoked from the same thread as the code being profiled in all cases of thread destruction, but that appears to be an unwarranted concern. You are the first person since months who claimed a possible use of ftstate. Please make sure that you really don't need it.

I'll do some more testing, but it could take me a couple of days. I do remember Martin Löwis mentioning to me that he thought it was possible to temporarily get two threadstate objects for the same thread, maybe when calling into a C function, and if that were the case, that could potentially cause problems for the profiler. Somebody else might have some more knowledgeable input there. One of the problems with this discussion occurring now is that while I'm intimately familiar with the profiler and existing tracing functionality, I'm not all that familiar with Python threads, so I need to learn a few more things before I can really jump into this work, and I'm concerned that something I don't know about is going to cause me to need the threadstate object in the frame.

My current plan is to pass a python interface to the threadstate object to the trace function, so it can build up it's own table of stats data per thread (or in the debugger's case, a thread-specific context). I had a concern about the threadstate not being relevant because of the profiler being called in a different thread than the traced code, which I now think is unlikely to occur in a way that I can't catch. However, if Martin is right and there can effectively be multiple threadstate objects for the current thread, that may present a problem for the profiler, since it's indexing its' stats data based on the previous threadstate object. My thought was that if the global threadstate object changes, hopefully at least the surrounding frame tstate member that I pass to the profiler would still be intact, which would be a reason for keeping the threadstate reference in the frame, although perhaps my assumption is false.

-- Nick

More information about the Python-Dev mailing list