merits of Lisp vs Python

[Graham Dumpleton]

On Mar 15, 7:22 am, j... at pobox.com (John J. Lee) wrote:
> "Graham Dumpleton" <Graham.Dumple... at gmail.com> writes:
> > On Mar 11, 12:31 pm, j... at pobox.com (John J. Lee) wrote:
> [...]
> > >mod_pythonrelies on an unsupported feature of Python, namely
> > > multiple interpreters --> risk of more pain with C extensions.
>
> > As usual, those bashing up onmod_pythontend not to really know what
> > they are talking about. :-(
>
> > Although multiple Python interpreters cannot be manipulated directly
> > from within a Python script, they can from the Python C API and it is
> > very much a feature of Python and has been for a long time.
>
> I didn't dispute that multiple interpreters are a feature of Python.
> I said that they are an unsupported feature -- at least, Martin
> v. Loewis says they're "just broken", which is close enough for me:
>
> http://groups.google.co.uk/group/comp.lang.python/browse_thread/threa...
>
> """
> In any case, it looks like that the "multiple interpreters" feature of
> Python is just broken.
> """

For mod_python at least, the issues described there do not present as
a problem because in mod_python sub interpreters are never destroyed
while the process is running. Thus as far as the implementation of
mod_python goes it is fine to key off the pointer to the interpreter
as one knows interpreters will never go away.

In the more general case I can see that it may be an issue for some
small percentage of C extension modules which may want to cache
information per interpreter. This though would only be the case if
they wanted to exclusively hold everything directly within the C code
space. Although it would perceivably slow access down, there is
nothing to stop such a module instantiating its own pseudo module
within the context of a sub interpreter using PyImport_AddModule().
This Python module could then be used to hold objects created by
PyCObject_FromVoidPtr() with access later being had by using
PyCObject_AsVoidPtr() after having looked up the object in the module.
As necessary, when creating these objects, the C extension module can
associate a cleanup function to be called when the object is destroyed
by virtue of the sub interpreter being destroyed. Thus the C extension
module would be able to cope with sub interpreters coming an going.

So, more work is required and some may be concerned about efficiency
and that a user may screw with the cached data from Python code, but
it is possible to have per interpreter information with a C extension
module.

> [...]> Even so, to get such a C extension module working in the context of
> >mod_pythonsimply means tellingmod_pythonto run that particular
> > application in the first interpreter instance by specifying the
> >mod_pythondirective:
>
> >   PythonInterpreter main_interpreter
>
> [...]
>
> Is it possible to askmod_pythonto start separate processes to serve
> requests, rather than "separate" interpreters?  We couldn't see a way.

Within the context of Apache it is possible to write modules which
could spawn off a separate daemon process to which requests could
later be passed for processing. An example of this included with
Apache is something like mod_cgid. Other examples of modules which
allow requests to be farmed off to separate processes, although they
work a bit differently, are mod_fastcgi, mod_scgi and mod_proxy_ajp.

To do something similar with mod_python isn't really practical because
of the way it hooks into more than just the response handling phase of
Apache. This concept though is being investigated for some version of
mod_wsgi after the initial version has been released. When
implemented, it would allow mod_wsgi to either handle WSGI
applications in the same style as mod_python within the Apache child
processes, or optionally farm the request off to a separate process
running either as the same user as Apache or a different user, in the
same style as mod_fastcgi and mod_scgi. The difference with mod_wsgi
would be that it would be one self contained module all managed from
Apache and would not require a separate executable or daemon process
to Apache to be run to which it would communicate with as the separate
daemon processes would ultimately just be a fork of the Apache parent
process and be running code from the Apache module itself. Also the
application scripts would be exactly the same no matter which mode it
was running in so no need to modify them in any special way to run
under the separate process.

Graham