Question about long-running web scripts

[Tim Golden]

On 26/10/2012 10:58, Gilles wrote:
> On Thu, 25 Oct 2012 14:24:16 +0100, Tim Golden <mail at timgolden.me.uk>
> wrote:
>>> But actually, I didn't mean one-shot scripts, where the Python
>>> interpreter + script must be loaded each time, but rather: If I leave
>>> a Python running in an endless loop, why not just use either CGI or
>>> some other basic way to call the script instead of FastCGI?
>>
>> In essence, you're describing FastCGI. A Python program (or, indeed, any
>> program) which uses FastCGI runs continuously and waits for the incoming
>> request on a TCP socket (instead of as a sys.stdin stream + env vars
>> immediately after process startup).
> 
> Thanks for the clarification.
> 
> Since, unlike PHP, the Python interpreter is not available in a
> FastCGI-capable version, this explains why the www server must be told
> which specific Python script to run through FastCGI.

I think that this is the distinction you're making:

PHP: mod_php (fastcgi mode) runs myscript.php

Python: <some python fcgi frontend>.py runs myscript.py

which is, essentially, true, not least because PHP and web apps are
pretty much synonymous in many people's minds. Both ways: the only thing
PHP does is web; the simplest route to a web app is PHP.

Certainly there are Python equivalents (mod_python, mod_wsgi, etc.)
which can run in effectively the same way as mod_php, and they could be
configured to run an fcgi frontend script, I presume. There's always a
certain confusion here because you can often one mechanisms (say,
mod_wsgi) to act as another (say legacy one-shot CGI) and because some
things are both mechanism and protocol and it's not always easy to tease
the two apart.


> 
> The reason I ask for all this, is that I want to understand how things
> work under the hood before relying on a Python framework to handle the
> nitty-gritty.

Good scheme.

TJG