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

Manlio Perillo manlio_perillo at libero.it
Tue Jul 8 20:45:00 CEST 2008


Donovan Preston ha scritto:
> 
> On Jul 7, 2008, at 6:11 PM, Phillip J. Eby wrote:
> 
>> At 02:12 PM 7/7/2008 -0700, Donovan Preston wrote:
>>> 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.
>>
>> I don't follow why you wouldn't just put that in the environ.  (If you 
>> need it to be carried back from the application, use mutable objects 
>> in the environ.)
> 
> Yes, the logical place to store it is in the environ, but this whole 
> thread is about having an api for doing request-local storage that 
> doesn't involve passing the request everywhere.
> 
> Here's what I am imagining:
> 
> There's just a module, called requestlocal or something. It has an API 
> just like threading.local(), except the implementation can be changed by 
> the wsgi server.
> 

Using greenlets, there is always a current greenlet, so you can use this 
for local storage.

A library function can check if there is an active greenlet, and use it 
as data key; otherwise it will use the current thread id.

However this will not work if you have an asynchronous server that does 
not make use of greenlets.

 > [...]


Manlio Perillo


More information about the Web-SIG mailing list