[Python-Dev] Last chance! (was: Does anybody really use frame->f_tstate ?)

Christian Tismer tismer at tismer.com
Fri Dec 19 04:32:37 EST 2003


Dear Python community,

since I didn't get *any* reply to this request,
either the request was bad or there is really
nobody using f_tstate in a way that makes it
urgent to keep.
I will wait a few hours and then make the change
to Stackless, and I'd like to propose to do the
same to the Python core.

Christian Tismer wrote:
> Hi colleagues,
> 
> this is my second attempt to get rid of the f_tstate field
> in frames. I need to find every user of this field.
> 
> What am I talking about?
> Well, Python always has a thread state variable which
> is a unique handle to the current thread. This variable
> is accessed in many places, and there exists a fast macro
> to get at it.
> Every executing Python frame also gets a copy on creation.
> In some cases, this frame->f_tstate field is used,
> in other cases the current tstate variable is used.
> 
> If this sounds foreign to you, please stop reading here.
> 
> -------------------------------------------------------------
> 
> I would like to get rid of the frame->f_tstate, and I'm trying
> to find out if there is a need for it. I don't need it,
> for Stackless, it is the opposite, it disturbs.
> 
> There was a small thread about this in June this year, where
> Guido convinced me that it is possible to create a traceback
> on a frame that comes from a different thread.
> 
> http://mail.python.org/pipermail/python-dev/2003-June/036254.html
> 
> Ok, this is in fact possible, although I don't think
> anybody has a need for this.
> 
> My question to all extension writers is this:
> If you use frame->f_tstate at all, do you use it just
> because it is handy, or do you want to use it for
> some other purpose?
> 
> One purpose could be that you really want to create a traceback
> on a different than the current thread. I have never seen this,
> but who knows, so that's why I'm asking the Python world.
> 
> In most cases, a traceback will be created on a frame
> that is currently processd or just has been processed.
> Accessing a frame of a different thread that is being processed
> might make sense for special debugger cases.
> 
> My proposal is
> --------------
> 
> a) change semantics of PytraceBack_Here to use the current tstate.
> 
> b) if such a special purpose exists, create a new function for it.
> 
> c) if urgent, different needs exist to keep f_tstate,
>    then let's forget about this proposal.
> 
> Especially for Stackless, I'd be keen of getting rid of this.
> 
> thanks for input -- chris


-- 
Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/




More information about the Python-Dev mailing list