On Mar 6, 2008, at 2:00 AM, Manlio Perillo wrote:
Maybe it can be of interest my work on adding asynchronous support
in WSGI.
I'm developing a WSGI module for the Nginx web server:
http://hg.mperillo.ath.cx/nginx/mod_wsgi/
The great advantage of Nginx over Twisted is it's support for
multiple worker processes; this helps a lot with application
"reloading" and for better support of I/O bound applications.
I'm not quite convinced that the concurrency model of the container is
the real bottleneck in WSGI applications as opposed to it's
synchronous API.
A Twisted WSGI container could use a process pool just as easily as a
thread pool, but you're still taking a properly asynchronous container
and letting it run an application that will block for a long period of
time.
I think that having a "pure" asynchronous WSGI implementation in
Twisted Web that implements this extension can be a good starting
point for trying to standardize asynchronous web applications.
P.S.: the wsgi.pause_output extension, proposed some years ago here
by Donovan Preston should be very easy to implement using ngx.poll,
and a pipe.
Does anyone support said extension? Does everyone support the same
pause_output? Or just functions of the same name?
It shouldn't be very hard to add support for it to Twisted.web2's WSGI
implementation either, but I don't much see the point if no one else
supports it. I'm not convinced that WSGI is at all a useful means of
writing asynchronous web applications. I think WSGI's only benefit is
that it allows you to almost write your application code once and run
it on multiple containers.
-David
"Usually the protocol is this: I appoint someone for a task,
which they are not qualified to do. Then, they have to fight
a bear if they don't want to do it." -- Glyph Lefkowitz
_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
