At 04:50 PM 12/17/2005 -0500, James Y Knight wrote:
>So this came up when I was writing the twisted WSGI support, but at
>that point I just took the most conservative view and forgot to
>revisit the issue.
>
>1)
>Take the following application:
>def simple_wsgi_app(environ, start_response):
> start_response("200 OK")
> yield str(thread.get_ident())
> yield str(thread.get_ident())
>
>Is there any guarantee that both times the iterator's .next() is
>called, they will be on the same thread?
I thought I included something in the spec to the effect that there's no
guarantee that each next() will be called in the same thread. But it might
just have been discussed and not actually edited into the spec.
>2)
>d = {}
>def simple_wsgi_app(environ, start_response):
> d[thread.get_ident()] = 0
> start_response("200 OK")
> yield "Start"
> assert d[thread.get_ident()] == 0
> d[thread.get_ident] += 1
> yield "Done"
>
>Is there any guarantee that this will work? That is, is it possible
>that at the first "yield", another application will be allowed to
>run, in the same thread?
>
>(Of course you'd probably actually want to use threading.local, not a
>dict of thread.get_ident, but, same idea.)
Yeah, that was the thing, I don't think we wanted to guarantee thread
affinity across yields, either in the sense of restricting a thread for one
app *or* an app to one thread.
This does mean that iterator-based apps can't rely on thread-local
variables. I've recently written a "Contextual" library that actually
makes it easy for the task controller to manage this, by swapping a
thread's context in and out when you switch between tasks, but of course it
won't work for anything that doesn't use Contextual variables. I
originally proposed Contextual for the stdlib in a pre-PEP, but Guido waved
it off on the basis that PEPs 342 and 343 aren't field-deployed yet and the
usefulness is unproven. WSGI, however, would be an example of a case where
contextual task-locals are needed even with today's Python, sans PEPs 342
and 343.
_______________________________________________
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
