[Web-SIG] WSGI async API

[Peter Hunt]

Okay. How will the gateway know to go to the next iteration of the
application? Constantly iterating over a bunch of empty strings while
waiting for output seems like a waste of cycles to me. Perhaps, for
async apps, there can be an environ["async.wakeup"]() method which
will tell the gateway to iterate until the next empty string?


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.
> 
>