On 24/01/16 17:08, Nathan Scott wrote:
Hi Ken,
...
The threading aspect is certainly a red herring - at the time it seemed the
only plausible explanation for pmDerivedErrStr returning NULL directly after
a failed pmRegisterDerived call. But as I should have realised, since the
second scenario in the qa/803 case actually triggers it (!), there are cases
where this NULL pointer is expected.
I've updated the commit - I think the fix remains sound (as the QA proved),
despite the earlier theory being incorrect. We could alternatively fix this
in python wrapper code (awkwardly), but providing a libpcp API with the more
convenient error handling properties still seems the better option to me.
I also updated pmDerivedErrStr(3) to document the NULL behaviour, and to add
mention of both higher level register APIs.
How does this look? ...
I don't like changes for the libpcp APIs that aim to fix problems we
don't fully understand.
...
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.
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.
|