471,319 Members | 1,585 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,319 software developers and data experts.

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

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:ti****@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/
Jul 18 '05 #1
0 927

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Christian Tismer | last post: by
2 posts views Thread by Bill Mill | last post: by
reply views Thread by Marcel - IDUG Europe 2005 | last post: by
2 posts views Thread by jermichael_duff | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.