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

Alan Kennedy py-web-sig at xhaus.com
Thu Sep 16 18:45:36 CEST 2004


[Phillip J. Eby]
 > I'd encourage people to experiment with async extensions like my
 > sleep/wake idea,

Actually, the more I think about it, the more I like your idea.

My solution of using a thread-safe condition variable as an optional 
attribute of application return objects is too heavyweight. Whereas your 
solution can be implement with complexity relative to the server. For 
example, on a single-process server, wsgi.sleep could be defined like this

def sleep():
	# return a closure wrapping a method which sets a simple binary

whereas a threaded server might use

import threading

def sleep():
	# return a closure wrapping a threading.Condition().set()

Also, having the wrapper in the environment means that its meaning can 
be changed by middleware.

The only thing I disagree on are the names "sleep" and "wake", which 
IMHO come with too many semantic hangovers from the threading world. 
When an application calls wsgi.sleep(), it's not really sleeping, it's 
just declaring that it currently has no output: a call to its iterator 
will succeed, but the returned value will be an empty string.

So basically, WSGI is providing an on/off indicator for every instance 
of a middleware stack, which indicates to the server if there is 
currently output available.

Thinking afresh.
================

The server is just acting as a mediator between the client and 
application. When the application has data, and the client is ready to 
receive data, the server transfers data between the two. But that client 
to application conversation is full-duplex, i.e. the client may be 
sending input to the application.

In an asynchronous situation, the application cannot simply do a 
blocking read on the input: that will tie up the server thread. So we 
need a way for the application to be notified/called when input becomes 
available from the client.

Perhaps we need to add an environment entry, e.g. "wsgi.input_handler", 
which the app uses to pass a callable to the server. This callable would 
be called whenever data became available on the input stream.

So how would that work in the middleware stack?

Would the first application in the stack set the callback for the 
input_stream, and perhaps not even invoke the next component up in the 
stack until some input has arrived? Does this mean that input handling 
will have to separated out into a new state in the server->application 
state model?

Or would each component in the stack set its own callback?

I'm beginning to think that we may have to treat output and input 
identically in WSGI: i.e. from the servers point of view, there is no 
difference between the application->client stream and the 
client->application stream: there is symmetry between server's 
connection to the client and server's "connection" to the application. 
Hmmm: Must think some more about this.

Regards,

Alan.


More information about the Web-SIG mailing list