[Web-SIG] WSGI async API
Phillip J. Eby
pje at telecommunity.com
Fri Oct 15 20:59:16 CEST 2004
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
> > >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.
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).
More information about the Web-SIG