back-monitor rationalization (Was: commit...)

[Pierangelo Masarati <ando@sys-net.it>]

Hallvard B Furuseth wrote:

> ando@OpenLDAP.org writes:
>  
>
> > 	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.
>  
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.

> Or maybe parts of monitor_back_initialize to monitor_back_db_init
> (bi->bi_db_init) - is there any need to set up back-montor if it is not
> used?
>  
Actually 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.

> BTW, I expect the structs in monitor_back_initialize should be static
> and maybe const.
>  
Nope: 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.

p.


   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497