On Fri, Aug 3, 2018 at 1:41 PM, Stefan Eissing
<stefan.eissing@xxxxxxxxxxxxx> wrote:
>
> Never looked at it before. How is the abstraction in apr_crypto supposed to manage
> the lifetime of the components? E.g. when calling apr_crypto_prng_init()
> one ties the whole openssl crypto's lifetime to the pool given there?
I'll talk about apr_crypto_lib_init() instead, which is where the
lifetime of the libs is handled (e.g. openssl), while
apr_crypto_prng_init() is only a consumer of apr_crypto_lib_init().
But yes, almost, apr_crypto_lib_init() maintains the
active/initialized libs in a hashtable (APR's root pool).
If the lib to init is not already there it's inited and a cleanup is
registered on the given pool to deinit (and remove from the global
hashtable).
>
> Does everyone check for APR_EREINIT? And if it comes, what is one supposed to do?
APR_EREINIT should at least no be handled as a real error, one can do
whatever when it (if it matters to not be the first consumer), but
usually nothing special has to be done: treat it like SUCCESS.
In httpd, it means that the core and/or a previously loaded module
already inited the lib, so be it, it will be deinited with that module
or the core, not this module's business.
But anyway, even if APR_SUCCESS is returned, there is nothing more to
do for the module, pconf will do the deinit job.
> Is a reference counting de-allocation not better fitting?
Not sure, at least for httpd, the first module loaded will be the last
cleaned up.
But refcounting and/or attaching the cleanup to the longest living
pool could be an option from a general usage POV.