[Date Prev][Date Next]
back-monitor rationalization (Was: commit...)
Hallvard B Furuseth wrote:
ando@OpenLDAP.org writes:Since only one is allowed, there's little use in separating be_X() from
be_db_X(); anyway, feel free to indicate what should be separated.
init.c 1.111 -> 1.112
more (in)sanity stuff
I haven't looked closely, but I imagine cleaner fix would be to move
parts of monitor_back_db_destroy (bi->bi_db_destroy) to bi->bi_destroy.
Or maybe parts of monitor_back_initialize to monitor_back_db_initActually that's not entirely correct. First of all I'd like to have
back monitor always on; furthermore, the capability to customize
back-monitor via the internal API presumes it's always initialized even
if it's not activated.
(bi->bi_db_init) - is there any need to set up back-montor if it is not
BTW, I expect the structs in monitor_back_initialize should be staticNope: in principle, one could even append subsystems dynamically (I'm
not sure the code is already there, but we're doing something like that
in customized modules we're developing for customers; it'll end up in
the source soon). In any case, subsystems could be activated only if
required; while in many cases the decision can be made at compile time
(e.g. thread info only if compiled with threads; SASL info --- none at
present, but there will be --- only if compiled with SASL), I expect in
some cases it could be determined by configuration.
and maybe const.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497