[Python-Dev] Last chance!
tim.one at comcast.net
Sun Dec 21 13:29:06 EST 2003
> 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:
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
More information about the Python-Dev