[Python-Dev] Last chance!
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 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
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.
More information about the Python-Dev