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 : [EMAIL PROTECTED] : http://blog.ianbicking.org
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
