[Web-SIG] Alternative to threading.local, based on the stack

[Ian Bicking]

Donovan Preston wrote:
>> To throw another wrench in things, with the Paste/WebError 
>> evalexception interactive exception handler, it restores this 
>> thread-local context so you can later execute expressions in the same 
>> context.
> 
> It seems to me that what is really needed here is an extension of wsgi 
> that specifies how to get, set, and list request local storage, and for 
> people to use that instead of the threadlocal module. Of course, for 
> threaded servers, they will just use the threadlocal module, but for 
> Spawning running in single-threaded cooperative mode it would use a 
> greenlet-local implementation, and for a hypothetical Twisted server 
> running a hypothetical asynchronous wsgi application it would just use a 
> random request id.

Well, it's really call-local, i.e., dynamic scoping.  Another option 
would be something like attaching this dynamic scoping to the frame 
objects themselves, in a way that evalexception could be aware 
(restoring them when trying to execute code in the context of some 
frame) and potentially greenlets could do the same thing.

It could be done in a WSGI-specific way, and that might be useful, but 
the general issue is applicable to more than WSGI.

Generally the problems we are talking about only occur when some kind of 
(semi-)transparent concurrency other than threads are used.  This 
includes greenlets, restoring a frame like in evalexception, and 
potentially generators with the app_iter.

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org