httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Dumpleton <>
Subject Re: Can a module find out, whether another module is present?
Date Tue, 05 Feb 2013 22:14:46 GMT
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

     * 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());


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.


On 6 February 2013 08:48, Mikhail T. <> 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:**
> 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

View raw message