On Tue, Feb 5, 2013 at 5:14 PM, Graham Dumpleton <[email protected]> wrote:
> Don't know if will be applicable in the case of those modules or not, but
> mod_python and mod_wsgi have similar conflicts over Python interpreter
> initialisation and destruction and have had to do a little dance over who
> gets precedence to ensure things don't crash.
>
> In the next version of mod_wsgi though I am dropping support for
> coexistence. I want to flag that fact with a big error message and refuse
> to start up if both loaded.
>
> What I have done is relied on the fact that mod_python
> uses apr_pool_userdata_set() to set a module specific key in the module
> init function to avoid doing certain interpreter initialisation on first
> run through the config when Apache is started.
>
> In other words, in mod_wsgi it will look for the mod_python key and
> complain.
>
> /*
> * No longer support using mod_python at the same time as
> * mod_wsgi as becoming too painful to hack around
> * mod_python's broken usage of threading APIs when align
> * code to the stricter API requirements of Python 3.2.
> */
>
> userdata_key = "python_init";
>
> apr_pool_userdata_get(&data, userdata_key, s->process->pool);
> if (data) {
> ap_log_error(APLOG_MARK, APLOG_CRIT, 0, NULL,
> "mod_wsgi (pid=%d): The mod_python module can "
> "not be used on conjunction with mod_wsgi 4.0+. "
> "Remove the mod_python module from the Apache "
> "configuration.", getpid());
>
> return HTTP_INTERNAL_SERVER_ERROR;
> }
>
> Don't know if the modules you are worried about use this convention of
> using apr_pool_userdata_set() to flag whether module init has already been
> run or not for configuration to avoid doing stuff twice which shouldn't.
>
module *modp;
for (modp = ap_top_module; modp; modp = modp->next) {
foo(modp->name);
}
>
> Graham
>
>
>
> On 6 February 2013 08:48, Mikhail T. <[email protected]> wrote:
>
>> On 05.02.2013 16:37, Nick Kew wrote:
>>
>>> But in general, querying another module, or knowing anything about
>>> its cleanups, would be a violation of modularity. If it's legitimate
>>> for a module to expose its inner workings, it can do so by exporting
>>> an API.
>>>
>>> Why the questions? Are you writing two modules that relate closely
>>> to each other?
>>>
>> I'm not writing them -- they already exist. The two Tcl-modules (rivet
>> and websh) both destroy the Tcl-interpreter at exit. The module, that gets
>> to run the clean up last usually causes a crash:
>> https://issues.apache.org/**bugzilla/show_bug.cgi?id=54162<https://issues.apache.org/bugzilla/show_bug.cgi?id=54162>
>>
>> If each module could query, whether the other one is loaded too, the
>> first one could skip destroying the interpreter -- leaving the task to the
>> last one. This approach would work even if only one of them has been
>> patched to do this.
>>
>> The modularity is a great thing, of course, but when the modules use
>> shared data-structures (from another library -- such as libtcl), they
>> better cooperate, or else...
>>
>> Yours,
>>
>> -mi
>>
>>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
