[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