[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
non-blocking?
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
applications.
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.
James
More information about the Twisted-web
mailing list