On Fri, Aug 3, 2018 at 1:41 PM, Stefan Eissing <[email protected]> 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.
