2008/10/14 Graham Dumpleton <[EMAIL PROTECTED]>: > > 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?
Apart from not being able to run legacy applications, no. What to do? Use one server for mod_python and another for mod_wsgi? Given today's prices that would not be all that expensive if i don't count the doubled server maintenance work time. Do you plan to break the coexistence in 3.0? 2.x would be maintained condescending with mod_python? What is the risk, if any, of people not adopting mod_wsgi because of its incompatibility with mod_python? What would be the cost of a compatibility mode compile option? I imagine it would be difficult to maintain two code paths. Although my concerns I'm all for making Apache/mod_wsgi the ultimate web python choice. Regards, Clodoaldo >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 -~----------~----~----~----~------~----~------~--~---
