On 08/08/2012 09:40 PM, [email protected] wrote:
>
> I tried to rework the attribuitions a bit since the
> levels of >>> were getting a bit much. I am not sure if
> I was successful or not in making in clearer who said
> what but.
>
I'll just cut the extra. We know what we're talking about.
>
> [rouilj 8/6]
> [rouilj 8/6] So add a field that is a pointer to a nagios maintained data
> [rouilj 8/6] store for each object. Where each object in the datastore is a
> [rouilj 8/6] key/value (blob pointer) pair. "adding items to the object"
> [rouilj 8/6] wasn't meant as add a new field. More along the lines of add a
> [rouilj 8/6] new item to a linked list in the object.
> [rouilj 8/6]
> [Andreas 8/7] Why on earth would you prefer O(n) complexity over O(1)?
> [Andreas 8/7] Do you realize that you're requesting something that's
> [Andreas 8/7] both slower and more complex than what I proposed?
>
> Arrays are fixed length. What do you expect to use for the size
> of the array? I agree being able to do an address lookup at
>
> array_start + n*(sizeof pointer)
>
> is a win, but it's also a good way to end up wasting a lot of
> space by oversizing the array at compile time to support an
> undeterminable number of brokers/plugins/modules.
Why on earth would you want to do that at compile time? You can
just
ary = malloc(sched_info.services * sizeof(whatever));
at runtime and waste zero memory instead. We don't have to put
everything on the stack.
> After all every
> object (host, service) will need this array. An alternative is
> to take some time to traverse a linked list (or binary tree, hash
> table ....) and reducing the amount of memory needed.
>
Linked list require more memory per stored object since they also
must have pointers to the next item in the array.
> Now if you are taking about mallocing the array and allowing the
> number of elements in the array to be set in the config file
> that's something different, but I saw no indication of that.
>
Not config file. I imagine 99.9999% of the usecases will be to
support arrays that are of exactly the same size as the number of
some type of objects.
> Ideally to save on memory you would want a configuation setting
> for each object type, but a single setting for all objects would
> probably work without too much waste.
>
What on earth do you want to store??
> [rouilj 8/3] Custom variables help a little bit but introduce the need to
> [rouilj 8/3] parse the value on every event which is not acceptable. The
> [rouilj 8/3] value should be parsed once into a quickly accessible form
> [rouilj 8/3] (e.g. bitfield) and carried around with the object.
> [rouilj 8/3]
> [andreas 8/3] Well, no. You might want to add things other than flags in
> [andreas 8/3] such variables and you may well have several modules at once
> [andreas 8/3] competing for the dubious honor of putting extra junk into
> [andreas 8/3] objects.
> [rouilj 8/6]
> [rouilj 8/6] The object carries the data as a linked list, static
> [rouilj 8/6] array of pointers.... rather than as a named item in the
> [rouilj 8/6] struct. As long as the name for each item is unique there
> [rouilj 8/6] isn't a problem. (e.g. ec_ in my examples). Nagios could
> [rouilj 8/6] even provide a register function to allow modules to
> [rouilj 8/6] determine which prefixes are already registered so if
> [rouilj 8/6] Eric Charles' plugin tries to register ec_ but my event
> [rouilj 8/6] correlation plugin already has ec_ loaded, it gets an
> [rouilj 8/6] error message and gets to chose a new prefix. Heck nagios
> [rouilj 8/6] could even return a prefix code that is used by the
> [rouilj 8/6] module. There are many ways to handle the issue.
> [rouilj 8/6]
> [andreas 8/7] Not really, no, because user documentation has to work
> [andreas 8/7] too or users won't be able to use Eric Charles' module
> [andreas 8/7] and yours at the same time.
>
> Yeah if you get a conflict like that, then the broker
> would have to be recompiled with a new prefix which
> could conceivably conflict again. However nagios
> wouldn't have to be recom
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]