Mladen Turk wrote: > Perhaps adding something like ap_preloaded_modules table to which > the module can assign itself. But I presume there'll be and issue > with the pool used for LoadModule.
Yes and no... the loaded module will be "cleaned up"/"unloaded" and reloaded (the register_hooks are called again). But the dso will be loaded 2x, the second time against the process pool, so it won't be "cleaned up"/"unloaded" for real until the final process teardown. Interesting Q to me, as the aspdotnet author, is that if I change the code so that mod_aspdotnet doesn't try to unload itself (see that asp_net_lock code that is commented out), but let the process pool cleanup of the mod_aspdotnet module do so, will it still bite the big one on the way down :) It's an interesting question, so I'll answer your question by hacking a bit at mod_aspdotnet to get it ready for such a new API and use the apr_dso loaded against the process pool, instead of locking the module with the win32 api.
