[Python-Dev] Last chance!

[Nick Bastin]

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