pcp
[Top] [All Lists]

Re: [pcp] pmLookupName sts differences

To: Martins Innus <minnus@xxxxxxxxxxx>, pcp@xxxxxxxxxxx
Subject: Re: [pcp] pmLookupName sts differences
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Wed, 15 Apr 2015 06:51:52 +1000
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <552D1EE1.5000600@xxxxxxxxxxx>
References: <551D8119.5010404@xxxxxxxxxxx> <552CA769.1070607@xxxxxxxxxxxxxxxx> <552D1EE1.5000600@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
On 15/04/15 00:06, Martins Innus wrote:

... From my perspective, it would be desirable
for pmLookupName give back correct information on valid metrics even if
the input list contains some bogus names.

Indeed.

My first inclination would be something like this ...

1. if numpmid == 1, then return 1 for success else an error code (<0) ... this special case is really required to allow a caller to discover _why_ a lookup failed for a particular metric

2. if numpmid > 1, then 3 cases apply
   - fatal error (no context, pmcd or pmns, ...) => return an error (<0)
   - all OK, return numpmid
- otherwise, return n (0 <= n < numpmid) as the count for those that are OK

On return, we guarantee that the first numpmid elements of pmidlist[] will be either PM_ID_NULL or a valid PMID.

This is not too far off the actual implementation today, so I think we're looking at (a) fixing the man page to accurately reflect the intended API, and (b) some bug fixes for some corner cases, and (c) audit all the callers of pmLookupName() in the PCP code base (there are lots of these O(100), but only a handful involve numpmid > 1).

This is much better than the ABI change I was fearing.

If someone can see a problem with this, now would be a good time to raise your concerns.

<Prev in Thread] Current Thread [Next in Thread>