Hi Ken,
----- Original Message -----
> > -----Original Message-----
> > https://docs.python.org/2/c-api/init.html
> > "In order to emulate concurrency of execution, the interpreter
> > regularly tries to switch threads"
>
> I've been mulling over this more.
Good thing you did!
> Can anyone explain why there are > 1 threads in play here?
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? ...
Changes committed to git://git.pcp.io/nathans/pcp.git master
Nathan Scott (1):
libpcp: add pmRegisterDerivedMetric for friendlier error handling
debian/libpcp3-dev.install | 1
man/man3/pmderivederrstr.3 | 17 ++++++++++++
man/man3/pmparseinterval.3 | 4 ++-
man/man3/pmregisterderived.3 | 50 ++++++++++++++++++++++++++++++++++++-
qa/803 | 26 +++++++++++++++++++
qa/803.out | 8 ++++++
qa/group | 1
qa/src/.gitignore | 1
qa/src/GNUlocaldefs | 2 -
qa/src/derived.c | 57 +++++++++++++++++++++++++++++++++++++++++++
qa/src/test_pcp.python | 2 -
src/include/pcp/pmapi.h | 1
src/libpcp/src/derive.c | 37 +++++++++++++++++++++++++++
src/libpcp/src/exports | 1
src/libpcp/src/getopt.c | 2 -
src/python/pcp/pmapi.py | 25 ++++++------------
16 files changed, 213 insertions(+), 22 deletions(-)
commit 7351fd9fc5872073ac79f75d8c507f5e9331a18f
Author: Nathan Scott <nathans@xxxxxxxxxx>
Date: Sun Jan 24 17:04:09 2016 +1100
libpcp: add pmRegisterDerivedMetric for friendlier error handling
Adds a convenience routine akin to pmRegisterDerived that does similar
error reporting to pmLoadDerivedConfig, and that is modelled on the
likes of pmParseInterval (caller gets a buffer to free on error).
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.
Test program added to exercise the C API, and python tests extended to
verify access from python-land, where errors parsing derived metrics
are now handled like all other exceptions.
Resolves Fedora BZ #1299806.
cheers.
--
Nathan
|