Re: svn commit: r1198930 - in /httpd/httpd/trunk: include/mod_core.h server/core.c server/main.c
> Am 03.08.2018 um 14:24 schrieb Yann Ylavic <ylavic.dev@xxxxxxxxx>:
> 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
>> 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?