At the moment mod_wsgi will coexist with mod_python in same Apache installation. This is done at some cost though because of mod_python being broken in various ways. Specifically, the following issues exist when both mod_wsgi and mod_python loaded at same time, because of mod_python being broken.
1. When mod_python initialises Python and itself, it doesn't use Python simplified GIL APIs and creates separate thread state objects instead. Because of this, mod_python will fail assertion checks because of incorrect use of Python C APIs, if Python is ever built with --with-pydebug option to configure. The mod_python package also doesn't release the GIL after it is initialised in Apache parent process, with it only being released in context of Apache worker processes. The mod_wsgi package in order to be able to coexist, has had to follow this flawed model and so mod_wsgi also doesn't use Python simplified GIL APIs correctly for certain things in main interpreter during initialisation. Thus it also fails when --with-pydebug used to configure Python. This flawed behaviour can also cause problems with some third party C extension modules. 2. Because mod_python is responsible for initialisating main interpreter, the mod_wsgi package has to defer to mod_python any subsequent destruction of the main interpreter. As it is, mod_python doesn't actually destroy main interpreter on process shutdown. This means that any Python threads running in main interpreter aren't cleaned up properly, nor any atexit registered callbacks triggered. That mod_python doesn't properly destroy Python main interpreter in Apache parent process on Apache restart also causes some problems with mod_python and mod_wsgi modules not necessarily unloading properly, thus forcing a full Apache stop if wanting to upgrade mod_wsgi module to new version. Not cleaning up Python in Apache parent process also may result in additional memory leakage on top of normal memory leaks Python has if Python was destroyed properly. In the early days, being able to coexist with mod_python was seen as required, else no one would try mod_wsgi. I feel it is about time with mod_wsgi 3.0 to say enough is enough and call mod_python for what it is, broken, and rule that mod_wsgi 3.0 cannot be used at same time as current versions of mod_python. Intent then would be to have mod_wsgi check if mod_python also loaded and if it is, refuse to initialise and thus stop Apache from starting until mod_python is removed. Having done that, can then fix mod_wsgi to use Python C APIs for simplified GIL state management and avoid the problems it causes. With mod_python out of the picture, can then also look at delaying initialisation of Python interpreter to the Apache worker processes and mod_wsgi daemon process. That is, Python would not be initialised in Apache parent process. Being able to do this would avoid memory leaks that Python exhibits when it is destroyed and reinitialised within the context of same process. See: http://code.google.com/p/modwsgi/issues/detail?id=99 Delaying initialisation and not doing it in parent is seen as reasonable as the time taken to initialise main interpreter isn't that great, namely in order of 10ms for modern Intel chips. Note that Python shared library would still get linked into Apache parent process, only initialisation of Python interpreter would be delayed. There may possibly be some other benefits that could come from delaying initialisation. Namely, the ability for daemon process groups to have different settings for PYTHONHOME, PYTHONOPTIMIZE etc. Overall, the only problem I can see coming from this is people who are using non content handlers in mod_python to do strange stuff, as they wouldn't be able to use mod_python to do that anymore. In mod_wsgi there already is support for access, authn and authz hooks, albeit with different APIs for usage in line with new Apache authnz providers. That just leaves people who use header parse handlers and fixup handlers to do fiddles on Apache request details. For a lot of these, mod_headers, mod_rewrite or mod_env could probably do the same thing, but possibly not everything. if there are strong enough arguments for mod_wsgi providing some sort of equivalent for doing these things, would entertain it, but one has to realise that people needing that sort of functionality would be very few. Anyway, if you have followed along with my ramble, can anyone see any reason why mod_wsgi shouldn't ditch the goal of happy coexistence with mod_python? Note that this wouldn't preclude mod_python and mod_wsgi working together again in the future if mod_python is fixed to do things correctly. Frankly though, am not sure if mod_python will ever be fixed completely as at the moment I am the only one doing any sort of patching of it. Comments? Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
