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:
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