[Web-SIG] WSGI thread affinity/interleaving

[James Y Knight]

On Dec 19, 2005, at 3:34 PM, Phillip J. Eby wrote:
> We should keep an eye, however, on the fact that the vast majority  
> of WSGI apps' requests can and should be handled in a single  
> synchronous iteration.  Multiple iterations are primarily useful  
> for large files, and streaming/push applications.  These are the  
> *only* reason the spec allows multiple writes or iterations.    
> Applications are supposed to do their own buffering in all other  
> cases, to minimize the number of blocks shuffled up and down the  
> middleware chain.
>
> That being the case, the simplest way to ensure thread affinity in  
> Twisted is to just farm out the entire processing of a given  
> request to a reactor.callInThread().

Yes, this is how it works currently. I was pondering relaxing that,  
if the spec allowed. I'm now pretty much convinced that WSGI servers  
_should not_ move applications among threads between yields of the  
result iterator, and thus, will be leaving the twisted code that  
handles this alone. Even though the requirement is not stated in the  
spec, it seems to be a practical requirement.

> The only applications for which this is not suitable will be large  
> files and streaming/push, which will tie up threads that they  
> probably shouldn't.

Large files is already supported by wsgi.file_wrapper, at least if  
you're not fiddling with the file as it goes through. That leaves  
streaming/push, which I'm not sure is a big enough use case to  
actually care about. At least IMO, if you want efficient streaming  
support without using up a bunch of threads, use twisted's APIs  
directly rather than some yet-to-be-invented WSGI extension.

James