[Web-SIG] Thread-management middleware components?
jim at zope.com
Thu Dec 15 22:39:07 CET 2005
Ian Bicking wrote:
> Jim Fulton wrote:
>>> Right now all threading and generally concurrency is handled by the
>>> server. Since it *has* to be handled by the server,
>> Why does it have to be handled by the server?
> Because most WSGI apps are blocking, so unless you want the server to be
> non-concurrent it has to handle this. Of course you design a
> non-concurrent WSGI server that *had* to be used with some threading
Actually, I suggest a WSGI server that *can* be used with
> WSGI doesn't seem like a good fit for that, though.
> I think in this particular case -- barring direct changes to Twisted --
> it would make more sense to build on Twisted's non-WSGI asyncronous
> application support, and build a threadpool that calls WSGI from there.
I don't want to maintain a non-WSGI interface and I don't want to
maintain my own WSGI Twisted interface.
> I think the server has to be synchronous by the time it calls a WSGI
> app. There's nothing saying that the WSGI support in Twisted is the
> WSGI support you have to use.
No, but I have good reasons for wanting to use it.
> My impression is that it is hard to standardize anything async-related
> because they use slightly different conventions on how to do async
> (e.g., Deferred vs. ad hoc callbacks). So... whatever standardization
> there is to be done there is probably below WSGI.
> Sure, but if there's only, say, 4 viable strategies and 3 serious async
> servers (are there even that many of either?) then it's easier just to
> figure out how to plug each strategy in on a case-by-case basis, and
> discuss the concrete issues with the server developers.
That's what I'll do if I have to.
Jim Fulton mailto:jim at zope.com Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
More information about the Web-SIG