[Python-Dev] Last chance!

[Tim Peters]

[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>.