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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
