Hi,
On 2015-11-27 16:16, Frank Ch. Eigler wrote:
> myllynen wrote:
>
>> In addition to some minor comments I had on IRC already, perhaps you
>> could comment these a bit higher level items on the list as well:
>>
>> - did you consider allowing NULL for out_type to signal native type?
>
> That would not make much sense to me. The application knows which
> pmAtomValue subfield it will look at in the result. Since the
> information as to data type is at some level fixed at compile time,
> the same data type ID might as well be passed to the fetchgroup API.
>
> For general purpose printing, just use PM_TYPE_STRING; the fetchgroup
> widgetry will convert numeric data.
ok, this widgetry makes things easier, avoiding pmLookup* calls in a
basic case "what's the current value for this metric" is valuable.
>> - how would you use the API with non-leaf PMNS nodes?
>
> These particular functions are not suitable for that, because they
> expect the caller to specify a specific locations / conversions for
> the outputs. That makes sense if the app knows what it wants.
>
> For purposes like pminfo or pmrep, a helper function could do a PMNS
> traversal, and within the callback dynamically allocate
> pmAtomValues/strdup-names to hold results and call pmExtendFetchGroup*
> on the leaf nodes. Maybe it's specialized & simple enough -not- to
> put it into libpcp.
Do you think something like below would be achievable or how would you
deal with N pmExtendFetchGroup_item calls in Python?
pmfg = None
atoms = []
metrics = []
def add_metric(metric):
metrics.append(metric)
pmExtendFetchGroup_item(pmfg, metric, None, None, atoms, PM_TYPE_STRING)
def test():
pmfg = pmCreateFetchGroup()
pmTraversePMNS("disk.dev", add_metric)
while True:
pmFetchGroup(pmfg)
for i, atom in enumerate(atoms):
print metrics[i] + " : " + atom.dref(PM_TYPE_STRING)
time.sleep(1)
If something like that would be possible, then I don't think it would be
libpcp-worthy. Somewhat unrelated, the pmSetMode magic mentioned earlier
[1], the dimensionality matching in fetchgroup.c and perhaps the scale
setting e.g. in pmval/pmdumptext/pmlogsummary might be nice to generalize.
1) http://oss.sgi.com/pipermail/pcp/2015-November/008742.html
By the way, one of the items in pmrep todo-list is handling counter
wrapping. According to PCPIntro(1) it's disabled by default nowadays
(not sure why it was changed), do you plan to handle that with fetch groups?
Thanks,
--
Marko Myllynen
|