Giving this problem some thought...

If an provider is linked to the 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 is still stuck in process to, so those should remain

Does this make sense?

Reply via email to