[Python-Dev] Last chance! (was: Does anybody really use
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.
> 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