[Web-SIG] WSGI async API

[Phillip J. Eby]

At 06:32 PM 10/15/04 +0000, exarkun at divmod.com wrote:
>On Fri, 15 Oct 2004 14:28:25 -0400, "Phillip J. Eby" 
><pje at telecommunity.com> wrote:
> >At 02:19 PM 10/15/04 -0400, James Y Knight wrote:
> > >On Oct 15, 2004, at 6:57 AM, Peter Hunt wrote:
> > >>So if I'm implementing a Twisted gateway, where should
> > >>request.finish() go? This has been puzzling me for some time...
> > >
> > >You'd call finish when the iterator from the iterable returned by the 
> WSGI
> > >app is exhausted and raises StopIteration, I think?
> >
> > Yes.  A Twisted gateway, to avoid blocking, would need to deferToThread()
> > the initial invocation of the WSGI app, and immediately return
> > server.NOT_DONE_YET.  A callback on the deferred would then deferToThread
> > an iteration on the return iterable, which would in turn defer to the next
> > iteration, and so on.  When you get an errback() of StopIteration instead
> > of a callback, you could finish().
> >
> > But all invocations of the application or any  method of any object
> > provided by the application *has* to be in a non-reactor thread, so as not
> > to block the reactor.  For example, there's no guarantee that simply
> > calling 'iter(result)' on the result returned by the application, won't
> > e.g. open a database connection or something.
> >
>
>   Does WSGI enforce any requirements about which thread the function is 
> first invoked in, and which thread(s) it is iterated in?

Not currently.


>   The scenario you described above would lead to an arbitrary thread 
> being used for each iteration.  I could see this being a problem for WSGI 
> applications which attempted to use thread local storage, assuming that 
> they would always be run in the same non-IO thread.

The discussion so far has been that the spec should prohibit applications 
and servers from depending on what thread a callable is invoked from, the 
result is iterated over, etc., as long as only one thread at at time does 
these things.  In other words, servers and applications may not use 
thread-local storage to determine invocation context, but they do not have 
to do any locking (except for the 'wsgi.multithread' case).