[Web-SIG] Proposal for asynchronous WSGI variant
Manlio Perillo
manlio_perillo at libero.it
Wed May 7 10:20:20 CEST 2008
Ionel Maries Cristian ha scritto:
> This is a very interesting initiative.
>
> However there are few problems:
> - there is no support for chunked input - that would require having
> support for readline in the first place, also, it should be the
> gateway's business decoding the chunked input.
Unfortunately Nginx does not yet support chunked input, so I can't help
here.
> - the original wsgi spec somewhat has some support for streaming and
> asynchronicity [*1]
Right, and in fact I have used this for the implementation of some
extensions in the WSGI module for Nginx.
> - i don't see how removing the write callable will help (i don't see a
> issue having the server providing a stringio.write as the write callable
> for synchronous apps)
To summarize: the main problem with the write callable is that after you
call it control is not returned to the WSGI gateway.
With an asynchronous server it is a problem since if you write a lot of
data the server may not be able to send it to the client.
This is not a problem if the application returns a generator, since the
gateway can suspend the execution until the socket is ready to send data.
With the write callable this is not possible,
In my implementation of WSGI for Nginx I provide two separate
implementation of the write callable:
- put the socket temporary in synchronous mode
(this is WSGI compliant but it is very bad for Nginx)
- buffer all the written data until control is returned to the
gateway (this is *not* WSGI compliant)
However if you use greenlets, then implementing the write callable is
not a problem.
> - passing nonstring values though middleware will make using/porting
> existing wsgi middleware hairy (suppose you have a middleware that
> applies some filter to the appiter - you'll have your code full of
> isinstance nastiness)
>
Yes, this should be avoided.
> Also, have you looked at the existing gateway implementations with
> asynchronous support?
> There are a bunch of them:
> http://trac.wiretooth.com/public/wiki/asycwsgi
> http://chiral.j4cbo.com/trac
> http://wiki.secondlife.com/wiki/Eventlet
> my own shot at the problem: http://code.google.com/p/cogen/
> and manlio's mod_wsgi for nginx
> (I may be missing some)
>
> However there is absolutely no unity in handling the wsgi.input (or
> equivalent)
>
The wsgi.input can be handled with ngx.poll:
c = ngx.connection_wrapper(wsgi.input)
...
ngx.poll_register(c, WSGI_POLLIN)
...
ngx.poll(1000)
Unfortunately I can not test if this is implementable.
I have some doubts.
> [...]
Manlio Perillo
More information about the Web-SIG
mailing list