Jim Fulton wrote: > Has anyone written any thread-management middleware components for WSGI? > Many web applications need to run application code in separate threads. > Often, the number of threads needs to be limited, either by throttling > the rate of thread creation, or by dispatching requests to a thread pool. > This is a capability that could be provided by a server, however, it seems > that it might be functionality better provided at an intermediate layer to > make it more pluggable.
Right now all threading and generally concurrency is handled by the server. Since it *has* to be handled by the server, I'm not sure what the advantage would be to duplicating that functionality? Well, strictly speaking you could have a server with wsgi.threaded and wsgi.multiprocess both being false, and the server presumably being asynchronous, but I think that's challenging to fit into the WSGI spec -- there was some discussion some time ago that dwindled off, and I don't think there was ever any resolution on handling asynchronous servers/apps in WSGI. I don't see a need for a lot of interchangeable thread pools, a handful at most should do. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ 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