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

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Pierangelo Masarati writes:
>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()

Well, you had to insert code to work around the fact that it doesn't
init/destroy resources in bi->{init/destroy} functions.  And if handling
of bi->{init/destroy} functions is changed someday, e.g. some new
dependency is introduced, then that might break back-monitor.

> anyway, feel free to indicate what should be separated.

Later... (need answer to the rest of this mail first.)

>> 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;

I don't see why, but maybe I've missed earlier discussions.
The #if(n)def SLAPD_MONITOR code, at least, doesn't seem intrusive.

> furthermore, the capability to customize back-monitor via the internal
> API presumes it's always initialized even if it's not activated.

If that's a problem for all backends, I suppose the fix belongs in the
config backend (or that all backends need to support it in some way).

If it's a problem for back-monitor in particular, can't it do whatever
the other backends do?

>> 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).  (...)

I don't see how that is affected by making those structs static instead
of auto variables.  Having them autos just means they are copied from
static storage into stack space when monitor_back_initialize runs, and
discarded afterwards.  And they still contains pointers to static
storage anyway.

-- 
Hallvard