[Web-SIG] WSGI async API

[Peter Hunt]

Here's what I was thinking.

To install an application on the Twisted library, you'd provide the
application callable and a boolean optional parameter which is whether
to run async or sync (defaults to sync). If it runs it sync, it
launches the WSGI in a new thread and does business as usual. If it
runs it async, the app *cannot* block; there needs to be a way around
it. How about I write a simple demo implementation of "wakeup" and you
guys can try it out?


On Fri, 15 Oct 2004 18:07:05 -0400, Phillip J. Eby
<pje at telecommunity.com> wrote:
> At 03:06 PM 10/15/04 -0400, Peter Hunt wrote:
> >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?
> 
> That's close to the first outstanding proposal for an async API, which went
> something like:
> 
>    resume = environ["wsgi.pause_iteration"]()
> 
> Which would pause subsequent iteration until 'resume()' was called.
> 
> By the way, if you're trying to implement async applications under WSGI,
> I'd really like to know more about what you have in mind, what your goals
> are, etc.  One of the problems in formulating a good WSGI API for async
> applications is that it's hard to envision use cases where somebody wants
> to write an async web application, and yet doesn't want to run it in a
> dedicated process.  So anything you could add to enlighten me on this point
> would make it easier for me to finalize an async API.  I've been leaving it
> up to the SIG so far, because I don't have as strong a vision of the use
> cases for async apps as I do for async servers.
> 
>