Open Stack

On 01/08/2016 09:51 PM, Mike Bayer wrote:
>
>
> On 01/08/2016 04:44 AM, Radomir Dopieralski wrote:
>> On 01/07/2016 05:55 PM, Mike Bayer wrote:
>>
>>> but also even if you're under something like
>>> mod_wsgi, you can spawn a child process or worker thread regardless.
>>> You always have a Python interpreter running and all the things it can
>>> do.
>>
>> Actually you can't, reliably. Or, more precisely, you really shouldn't.
>> Most web servers out there expect to do their own process/thread
>> management and get really embarrassed if you do something like this,
>> resulting in weird stuff happening.
>
> I have to disagree with this as an across-the-board rule, partially
> because my own work in building an enhanced database connection
> management system is probably going to require that a background thread
> be running in order to reap stale database connections.   Web servers
> certainly do their own process/thread management, but a thoughtfully
> organized background thread in conjunction with a supporting HTTP
> service allows this to be feasible.   In the case of mod_wsgi,
> particularly when using mod_wsgi in daemon mode, spawning of threads,
> processes and in some scenarios even wholly separate applications are
> supported use cases.

[...]

> It is certainly reasonable that not all web application containers would
> be effective with apps that include custom background threads or
> processes (even though IMO any system that's running a Python
> interpreter shouldn't have any issues with a limited number of
> well-behaved daemon-mode threads), but at least in the case of mod_wsgi,
> this is supported; that gives Openstack's HTTP-related applications with
> carefully/thoughtfully organized background threads at least one
> industry-standard alternative besides being forever welded to its
> current homegrown WSGI server implementation.

This is still writing your application for a specific configuration of a 
specific version of a specific implementation of the protocol on a 
specific web server. While this may work as a stopgap solution, I think
it's a really bad long-term strategy. We should be programming for a 
protocol specification (WSGI in this case), not for a particular 
implementation (unless we need to throw in workarounds for 
implementation bugs). This way of thinking led to the trouble we have 
right now, and the fix is not to change the code to exploit another 
specific implementation, but to rewrite it so that it works on any 
compatible web server. If possible.

At least it seems so to my naive programmer mind. Sorry for ranting,
I'm sure that you are aware of the trade-off here.

-- 
Radomir Dopieralski