[Christian Tismer]
I did a similar research on Friday, but for some reason it was not accepted by python.org, as it appears. (why, only 4 k, yours was 10?)
Your original was accepted: http://mail.python.org/pipermail/python-dev/2003-December/041287.html I think there may have been a long delay in sending it out, though, perhaps related to the python.org domain transfer, or to hardware fiddling recently done at mail.python.org's physical site. Whichever, it's in the archive, and I got it via email too.
My summary: f_tstate not needed!
More, it seems conceptually flawed, albeit subtly. Python's runtime is, in effect, simulating thread-local storage by hand, and the current value of _PyThreadState_Current always points to a PyThreadState struct holding the currently-executing thread's *conceptual* thread-local storage. If we were able to use honest-to-goodness TLS instead, it wouldn't have been possible (well, not w/o ugly hacks) for a frame to use the values of these guys associated with any thread other than the one currently executing. Or, IOW, the existence of f_tstate creates a possibility for inter-thread mixups. Still, the possibility to switch threads across generator resumptions seems darned hard to view as "a feature". I'd advise people not to rely on it <wink>.