[Python-Dev] Pre-PEP: Task-local variables
Phillip J. Eby
pje at telecommunity.com
Thu Oct 20 06:13:29 CEST 2005
At 07:30 PM 10/19/2005 -0700, Josiah Carlson wrote:
>What about a situation in which corutines are handled by multiple
>threads? Any time a corutine passed from one thread to another, it
>would lose its state.
It's the responsibility of a coroutine scheduler to take a snapshot() when
a task is suspended, and to swap() it in when resumed. So it doesn't
matter that you've changed what thread you're running in, as long as you
keep the context with the coroutine that "owns" it.
>While I agree with the obvious "don't do that" response, I don't believe
>that the proposal will actually go very far in preventing real problems
>when using context managers and generators or corutines. Why? How much
>task state is going to be monitored/saved? Just sys? Perhaps sys and
>the module in which a corutine was defined?
As I mentioned in the PEP, I don't think that we would bother having
Python-defined variables be context-specific until Python 3.0. This is
mainly intended for the kinds of things described in the proposal: ZODB
current transaction, current database connection, decimal context,
etc. Basically, anything that you'd have a thread-local for now, and
indeed most anything that you'd use a global variable and 'with:' for.
> Eventually you will have
>someone who says, "I need Python to be saving and restoring the state of
>the entire interpreter so that I can have a per-user execution
>environment that cannot be corrupted by another user." But how much
>farther out is that?
I don't see how that's even related. This is simply a replacement for
thread-local variables that allows you to also be compatible with
"lightweight" (coroutine-based) threads.
More information about the Python-Dev