[Chicago] Status of wsgi

Jordan Bettis jordanb at hafd.org
Thu Oct 11 06:14:36 CEST 2012

On 10/10/2012 08:48 PM, JS Irick wrote:
> Good evening Jordan-
> Can you explain what you mean by "doesn't support async"?  Asynchronous processes, asynchronous JavaScript, or something else?  I have pretty strong memories of using Ajax regularly from within django. (Basically using templates to build simple Json web services). 

I mean asynchronous server responses. Which is to say, a server receives
a request, processes it for a time, makes a request on some other
service, and then sets the request aside, to handle other requests.
Later, when that other service returns its response, the server finishes
processing that request and returns it to the client.

Suppose you have a site which has a text search function. Your website
is a 'standard' webapp which has a number of worker threads which
receive requests, and process them into responses. But because search
takes so much time, that's separated out into a dedicated process. When
a worker receives a search request, it passes it on to the search server.

But if there's no mechanism for setting the request aside, the the
worker thread has to sit around doing nothing while the search server
does its thing. An asynchronous framework would let the worker set the
request aside and process new requests while it's waiting for the
response from the search server.

This is irrelevant to ajax because ajax is about client-side
asynchronous requests. From the view of the server, each ajax call is a
typical request-response synchronous cycle.

WSGI doesn't support setting a request aside and processing others. When
a request is made on a worker through WSGI, the worker is expected to
generate a response *before* starting work on another request.

More information about the Chicago mailing list