pcp
[Top] [All Lists]

Re: [pcp] pmRegisterDerived return values

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: [pcp] pmRegisterDerived return values
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Sun, 24 Jan 2016 17:49:44 -0500 (EST)
Cc: pcp developers <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <56A4B274.8060308@xxxxxxxxxxxxxxxx>
References: <569CB025.4070603@xxxxxxxxxx> <569CB7C5.7030803@xxxxxxxxxxxxxxxx> <1305297915.11201184.1453261568406.JavaMail.zimbra@xxxxxxxxxx> <007401d155a4$fd1e1660$f75a4320$@internode.on.net> <587895039.13498181.1453615697410.JavaMail.zimbra@xxxxxxxxxx> <56A4B274.8060308@xxxxxxxxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: pYaJ/B+Fe3+uswlaUI1XIPOZpxLTKw==
Thread-topic: pmRegisterDerived return values

----- Original Message -----
> On 24/01/16 17:08, Nathan Scott wrote:
> > ...
> >      This handles the case where pmRegisterDerived fails but
> >      pmDerivedErrStr
> >      still returns NULL.  Makes life easier for high-level code like python
> >      wanting to access the derived metrics parser diagnostics.
> 
>  From the original design point, this is just wrong.

Which bit?  The "still returns NULL"?  Or the complete error strings?
I agree returning NULL was quite a surprise, but I think we do need to
fix up the error handling to be more convenient and consistent here.

> I'd like to revisit pmRegisterDerived() and understand why it fails
> without setting an error for pmDerivedErrStr() to return.
> 
> Unfortunately I won't be able to do this before Tue, or may be Wed,
> which is very late in the release cycle.

This is quite a self-contained change, and we seem to have a good
handle on it now - so it's likely safe to leave it till mid-week (or
would you prefer to defer till next release?  s'ok by me too).

cheers.

--
Nathan

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