[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