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.
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
>
>
