[Web-SIG] WSGI thread affinity/interleaving
James Y Knight
foom at fuhm.net
Mon Dec 19 23:22:09 CET 2005
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.
More information about the Web-SIG