Giving this problem some thought... If an aprfoo-1.so provider is linked to the libfoo.so library, and we track the init state and perform it only once, it seems that apr should never try to de-init or unload the .so provider for the lifespan of the process.
This should help us avoid some redundant initialization. While we could free resources atexit(), any spin of trying to repeatedly unload and reload any .so provider seems to be inherently messy and unstable. We see this issue with mod_ssl, etc, where the statics may be freed and reinitialized, and causes the resource leakage mentioned by Yann. Once loaded and initialized, we recieve no benefit from repeatedly altering the processes' library mmaps, and doing so after we spin up contending threads is an even worse scenario. Leaving them loaded should not have an adverse effect, and if it becomes swapped out due to lack of use during the lifespan of the process, should not be particularly harmful. While httpd modules are often unloaded and reloaded, the underlying libfoo.so is still stuck in process to libapr-1.so, so those should remain stable. Does this make sense?
