[Twisted-web] Re: [Web-SIG] WSGI woes

James Y Knight foom at fuhm.net
Thu Sep 16 09:14:20 MDT 2004

On Sep 16, 2004, at 2:37 AM, Phillip J. Eby wrote:
> Reading the rest of your post, I see that you are actually addressing 
> the issue of asynchronous *applications*, and I have only been 
> addressing asynchronous *servers* in the spec to date.  (Technically 
> "half-async" servers, since to be properly portable, a WSGI server 
> *must* support synchronous applications, and therefore an async WSGI 
> server must have a thread pool for running applications, even if it 
> contains only one thread.)

 From the point of view of Twisted as the server, running a WSGI 
application, the big question is:
Can you (as a host server) assume WSGI applications will run 

The answer is clearly No and I don't imagine that would change. (well, 
right now it's currently not even possible to write a non-blocking WSGI 
application, but even if it were..). The only sensible thing is to 
assume a WSGI app will block for some arbitrarily long amount of time. 
Therefore, the only solution is to spawn threads for simultaneous WSGI 

This is not the Twisted Way, BUT, it is very clearly doable in Twisted, 
so it's not like the WSGI spec is unimplementable. For some people it 
might be perfectly acceptable to have an async base Twisted webserver 
running multi-threaded user code. I do not care much about doing that 
myself, but it should be fairly easy to write the WSGI layer to make 
this happen, and I would be happy for someone else to do so and 
contribute it to twisted.

So, basically, I concur: WSGI is implementable for async servers, but 
only to implement blocking applications.

> However, I'm not certain that it's actually possible to support 
> *portable* asynchronous  applications under WSGI, since such 
> asynchrony requires additional support such as an event loop service.  
> As a practical matter, asynchronous applications today require a 
> toolset such as Twisted or peak.events in addition to the web server, 
> and I don't really know of a way to make such applications portable 
> across web servers, since the web server might use a different toolset 
> that insists on having its own event loop.  Or it might be like 
> mod_python or CGI, and not really have any meaningful way to create an 
> event loop: it could be utterly synchronous in nature and impossible 
> to make otherwise.
> Thus, as a practical matter, applications that make use of 
> asynchronous I/O *may* be effectively outside WSGI's scope, if they 
> have no real chance of portability.  As I once said on the Web-SIG, 
> the idea of WSGI is more aimed at allowing non-Twisted apps to run 
> under a Twisted web server, than at allowing Twisted applications to 
> run under other web servers!  The latter, obviously, is much more 
> ambitious than the former.

Yes, there is no way that I can see to make WSGI suitable for writing 
async applications without significant work.  There are two obvious 
issues: the input stream only provides blocking read(), not a 
selectable fd, and there is no way to pause output.

If the write callback was extended into a write/finish callback, it 
wouldn't completely fix the second problem. Twisted would have to call 
the write() callback from its reactor loop (having no access to the 
original request thread). Especially if there is any middleware, the 
*write* might block! There's also the question of whether the write() 
and finish() methods are threadsafe or not -- would it even be safe to 
call from a separate thread from that in which the request was started?

Writing an async application *is* an interesting question, because 
then, possibly, you could take the framework half of twisted web and 
run it as a WSGI application. However, if this question is punted by 
WSGI (as I think is likely a good idea..), twisted web framework can 
continue to work with other servers by using HTTP proxying -- which is 
a _perfectly good_ solution, and something major webservers already 
support. HTTP is a pretty good protocol for talking between webservers 
and webapps.

Also, if WSGI becomes really popular on servers that cannot do HTTP 
proxying natively, twisted could provide a WSGI "application" that 
simply proxies the requests over a socket to a separate twisted web 
server process. This would provide essentially no advantage to HTTP 
proxying where that works, however.


More information about the Twisted-web mailing list