On Mar 15, 7:22 am, [EMAIL PROTECTED] (John J. Lee) wrote: > "Graham Dumpleton" <[EMAIL PROTECTED]> writes: > > On Mar 11, 12:31 pm, [EMAIL PROTECTED] (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 -- http://mail.python.org/mailman/listinfo/python-list
