Python does not play well with others

[Graham Dumpleton]

On Feb 4, 1:05 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> "Paul Boddie" <p... at boddie.org.uk> writes:
>> Probably the biggest inhibitor, as far as I can see, has been the
>> server technology chosen. Many hosting providers have historically
>> offered no better than CGI for Python, whilst PHP runs within Apache
>> itself, and it has previously been stated that mod_python has been
>> undesirable with regard to isolating processes from each other.
>> Consequently, a number of Python people seem to have held out for
>> other "high performance" solutions, which various companies now offer.
>
> Your point that shared hosting with Python isn't so easy because of
> insufficient isolation between apps is valid.  Maybe Python 3.0 can do
> something about that and it seems like a valid thing to consider while
> fleshing out the 3.0 design.

To clarify some points about mod_python, since these posts do not
properly explain the reality of the situation and I feel people are
getting the wrong impression.

First off, when using mod_python it is possible to have it create
multiple sub interpreters within each Apache child process. These
distinct sub interpreters can be linked to different parts of the URL
namespace. This means that it is possible to host more than one
mod_python application where each executes within in their own
distinct sub interpreter. The outcome of this is that each application
can have their own sys.path, own os.environ, own sets of modules and
potentially with different versions of some module.

Maintaining separation using sub interpreters eliminates the bulk of
problems with applications interfering which each other at least
within a process. Some problems can still arise though where third
party extension modules for Python aren't written so as to be usable
from multiple sub interpreters at the same time however. This is not a
failing of mod_python though, but a failing of the module writers.

The main area where interference can occur is where applications needs
to write to the file system. This is because all code will be
executing as the user that Apache runs as. Thus, distinct applications
could overwrite each others data within the file system. On one level
this just means that applications need to be configured to always use
their own part of the file system. For example, if using the support
in mod_python for sessions, the distinct applications should perhaps
use separate session databases rather than use the same common
database. Ultimately though, a rogue application could write where
ever it wants to, but from what I know (and could be wrong), this
isn't different to other languages systems within Apache such as PHP
and mod_perl.

Another possibility for interference is where an application simply
does something bad like get stuck in a tight loop or consume lots of
memory. Such an event can possibly interfere with other applications,
even across language boundaries, however, how bad the impact will be
depend on what MPM is used by Apache.

If "prefork" MPM is used, then the request being handled by that
application is the only thing which would be running within that child
process at that particular time. Thus, if it stops the functioning of
just that one process it doesn't matter as Apache will just farm
requests off to other child processes. If that initial child process
crashes because of the problem, then again it doesn't matter as Apache
will just create another child process to replace it and will
otherwise keep running.

If the "worker" MPM is used the impact can be greater as there could
be other requests being handled concurrently within the same child
process and the performance of those requests may be hindered. If the
worst happens and the child process crashes, only other requests being
handled within that specific child process would be affected, those in
other child processes would again continue unaffected as would Apache
as a whole.

The worst case is the "winnt" MPM (ie., Windows boxes). This is
because there is only one Apache process and thus a rogue application
can affect the whole Apache web server.

It should be highlighted though that this class of problem is not
unique to Python or mod_python as you could get rogue code in a PHP
page or mod_perl application just as easily.

What it all really comes down to is that the only features that are
really missing are the ability for distinct applications to run as
distinct users, or for applications to run inside of some sort of
chroot environment. Some aspects of this are addressed by FCGI and
SCGI, but again lack of this feature within mod_python itself is not
unique to it and that as far as I know is also going to be an issue
for other language systems for Apache such as PHP or mod_perl.

Having said all that, perhaps those who are complaining about lack of
support for specific features in mod_python can now clarify what
actually you are talking about. At the moment the brief comments being
made seem to possibly cover some things that mod_python can already do
but may not be obvious.

Graham