[Python-Dev] Pre-PEP: Task-local variables

[Phillip J. Eby]

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.