[Web-SIG] WSGI async API
floydophone at gmail.com
Sat Oct 16 02:05:08 CEST 2004
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.
More information about the Web-SIG