[Web-SIG] WSGI async API

[exarkun at divmod.com]

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

  Jp