[Web-SIG] WSGI async API

[Phillip J. Eby]

At 06:07 PM 10/15/04 +0000, exarkun at divmod.com wrote:
>On Fri, 15 Oct 2004 14:51:54 -0300, Carlos Ribeiro <carribeiro at gmail.com> 
>wrote:
> >On Fri, 15 Oct 2004 13:24:19 -0400, Peter Hunt <floydophone at gmail.com> 
> wrote:
> > > Essentially, Twisted.Web gives you something like this:
> > >
> > > class MyResource(resource.Resource):
> > >     def render(self, request):
> > >         return "content here" # you could also do 
> request.write("content here")
> > >
> > > If you do an async call, you have to use request.write() to write the
> > > data, return server.NOT_DONE_YET from the render() method, and call
> > > request.finish() to finish the request.
> >
> > Just curious, so forgive me from jumping into the middle of the
> > discussion. Isn't this one of the scenarios where output generators
> > are most useful? Assuming that Twisted supported it, you could yield
> > lines until there were nothing else to write. Did I get it right?
> >
>
>   Only if you can also signal to the code which is iterating the 
> generator that it should stop iterating it for a while, otherwise user 
> code might be called upon for bytes before they are available.
>
>   If I have understand the conversation on the matter then this caveat is 
> a main stumbling block for the async wsgi api.

Yes.

Essentially, in order to write a Twisted WSGI gateway (for running WSGI 
apps under Twisted), you *must* use threads (e.g. deferToThread) for 
invoking the WSGI application and iterating over its result, because a 
synchronous WSGI app might block during either operation.

However, note that an asynchronous server/gateway is free to delay 
requesting another iteration, if the application yields an empty 
string.  So, the minimum "asynchronous API" is simply backing off the 
iteration rate when the application yields empty strings.

But, a more sophisticated API would of course only iterate when there was 
data available to be iterated.