> Am 03.08.2018 um 14:24 schrieb Yann Ylavic <[email protected]>:
>
> 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.
But that assumes that no module uses a function that uses a function...that
calls crypto_init on a temp pool during conf test, for example, right?
