[Web-SIG] Thread-management middleware components?

[Jim Fulton]

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 
> middleware. 

Actually, I suggest a WSGI server that *can* be used with
threading middleware.

 > 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

-- 
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