2008/10/16 Carl Nobile <[EMAIL PROTECTED]>:
> Graham,
>
> Would it be possible to detect in code if mod_python has fixed their issues?
> If so you could do this test in mod_wsgi then continue to load mod_wsgi
> based on weather or not mod_python became compliant with the newer GIL
> calls.
As mod_python code is now, no. Since though I would likely be the
person to change mod_python to fix it, I can add a distinguishing
marker.
What I was intending to do was modify code in mod_python that says:
const char *userdata_key = "python_init";
...
apr_pool_userdata_get(&data, userdata_key, s->process->pool);
if (!data) {
apr_pool_userdata_set((const void *)1, userdata_key,
apr_pool_cleanup_null, s->process->pool);
return OK;
}
Such that instead of setting its marker to '(const void*)1', to set it
to a marker value which is the version string, or combined version
number as integer.
Thus, mod_wsgi could look for the marker and if != '(const void*)1'
assume that mod_python has been fixed. If need be it could look
further at the value of the marker if mod_python is changed again
later and mod_wsgi has to adapt differently again.
This will solve the GIL locking compliance issues, but if mod_wsgi
were to go to deferred initialisation of Python in child processes,
using mod_python at same time will obviously disable that and it would
return to initialisation in parent process as mod_python will take
control. Unless I at the same time rewrite mod_python to also do
deferred initialisation and make mod_wsgi take precedence over
mod_python.
So, yes there are ways and have been investigating them. It is just a
pain to have to maintain such fiddles. Unfortunately I probably will
not have a choice and will have to leave with such fiddles.
Graham
> On Tue, Oct 14, 2008 at 11:34 PM, Graham Dumpleton
> <[EMAIL PROTECTED]> wrote:
>>
>> 2008/10/15 MilesTogoe <[EMAIL PROTECTED]>:
>> >
>> > Graham Dumpleton wrote:
>> >> 2008/10/15 Clodoaldo Pinto Neto <[EMAIL PROTECTED]>:
>> >>
>> >>> 2008/10/14 Graham Dumpleton <[EMAIL PROTECTED]>:
>> >>>
>> >>>> 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?
>> >>>
>> >>
>> >> Would only do this in mod_wsgi 3.0. Version 2.X would still be
>> >> maintained and important/easy fixes backported as necessary.
>> >>
>> >> The error message that mod_wsgi 3.0 would produce if mod_python also
>> >> loaded at same time could even explicitly state to use older 2.X
>> >> versions if need support for mod_python at same time.
>> >>
>> >> Having to use 2.X shouldn't be a problem for people as long as
>> >> important fixes made to it, as the WSGI interface doesn't change. All
>> >> you loose from using mod_wsgi 3.0 would be new features or
>> >> improvements.
>> >>
>> >>
>> >>> What is the risk, if any, of people not
>> >>> adopting mod_wsgi because of its incompatibility with mod_python?
>> >>>
>> >>
>> >> The biggest obstacle at present that I can see in respect of people
>> >> using mod_wsgi over mod_python is that the Django folks still push
>> >> mod_python as the preferred option. That and a few web pages and
>> >> people in IRC channels still referring to mod_wsgi as young, immature
>> >> and potentially full of bugs. I ask, how many years and how many major
>> >> sites are needed before people will accept it is working fine. :-(
>> >>
>> >> Other major Python web application frameworks openly push WSGI as one
>> >> of the options, if not preferred option. Beyond that, any stuff which
>> >> is bound to mod_python either has little mindshare so as not to be
>> >> worried about, or is a legacy application for which there are most
>> >> likely alternatives.
>> >>
>> >> Of course, this may be fine for people starting on new applications,
>> >> who can choose, but obviously a problem for all those old in house
>> >> applications that use mod_python.
>> >>
>> >>
>> >>> What would be the cost of a compatibility mode compile option? I
>> >>> imagine it
>> >>> would be difficult to maintain two code paths.
>> >>>
>> >>
>> >> If I didn't want to play with the idea of pushing Python
>> >> initialisation into child processes, probably not that hard to
>> >> maintain support for mod_python. I would though change it so that it
>> >> dynamically detected whether mod_python was used and only include
>> >> compatibility hacks/wrong behaviour if mod_python being used. Even
>> >> with an option to defer Python initialisation to child processes being
>> >> optional, albeit disabled when mod_python used, supporting mod_python
>> >> still probably isn't that hard, but just would prefer to draw a line
>> >> and not have to have the hacks and complicate the code.
>> >>
>> >> The only other option would be to fix mod_python at same time and say
>> >> that if you want mod_python at same time, to use mod_python 3.4 (not
>> >> yet available at this stage obviously). Even if mod_python code fixed
>> >> in subversion repository, not sure could even muster a release as
>> >> don't even have enough active developers on mod_python at the moment
>> >> so as to get the required votes to approve it. Would need to drag some
>> >> of the prior developers on project management committee out of slumber
>> >> to do it.
>> >>
>> >>
>> > Sounds like a good idea but there will be effort required to spread the
>> > word - probably need a good post on the Django community blog page -
>> > then maybe some patches to their docs.
>> >
>> > Also some info to the major hosting services (ie webfaction, linode,
>> > slicehost...) with a press release for them to send to customers and
>> > docs on how users should install or use mod_wsgi.
>> >
>> > There will be a surge of questions so best to have faq ready.
>>
>> I think you may be overestimating how many people would be affected,
>> or at least how many would need both modules. Most cases I have seen
>> where people have both loaded are people who know no better and just
>> enabled lots of Apache modules for no reason, or moved to mod_wsgi and
>> didn't bother disabling mod_python at the same time. In both case they
>> don't generally use both.
>>
>> As for a FAQ entry, there is already stuff in FAQ and documentation
>> warning about using mod_python and mod_wsgi together and people seem
>> not to read that based on number of problems one sees on various IRC
>> channels deriving from them doing just that.
>>
>> 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
-~----------~----~----~----~------~----~------~--~---
