>>> On 7/2/2008 at 3:57 AM, in message
<[EMAIL PROTECTED]
, <[EMAIL PROTECTED]> wrote:
>
>
>
> I've just been looking at mod_multicpu.c
>
> I notice a lot of code is required for converting the metric name string
> to an individual CPU number, and deciding which metric function to
> invoke.
>
> It would seem much simpler to have this data in the Ganglia_25metric
> type, by adding some kind of private pointer:
>
> struct Ganglia_25metric
> {
> int key;
> string name<16>;
> int tmax;
> Ganglia_value_types type;
> string units<32>;
> string slope<32>;
> string fmt<32>;
> int msg_size;
> string desc<__MAX_DESC_LEN>;
> int *metadata;
> void *pvt; /* Private data for internal use by the metric/module */
> };
>
> Individual metrics could then use the pointer to access some struct
> containing meaningful data (e.g. CPU name, function pointer).
>
You can actually do something very similar now without extending the
Ganglia_25metric structure. The index that is passed into the module handler
always identifies the metric definition within the array of Ganglia_25metric's.
All your module needs to do is use that index as a unique key to reference
your own internal data. One way of doing that is to define an array of
internal structures that hold whatever data you want. Then as you create each
Ganglia_25metric definition in your metric_init() function and add it to the
array, you also create a corresponding internal data structure and add it to
your internal array. Since the index into each array remains the same, when
your metric_handler() function is called with an index, you can simply use the
same index to find the Ganglia_25metric and your internal extra data. This is
actually how the extra data, which includes the handler function pointer, is
attached to each python metric in the mod_python module. Another way
to do it would be to use an apr_hash with either the metric name or the index
as the key. Then it is just a simple hash lookup using the index or the metric
name to get any extra data you want.
The multicpu module is doing the function resolution in the way you currently
see it basically because it was one of the first modules that I wrote. If I
were to do it again, I would probably use a better lookup mechanism.
Brad
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
