Ken McDonell wrote:
On Wed, 2010-05-05 at 11:42 +1000, Greg Banks wrote:
As of Mon 15 March there's a process in our product which uses the async
API to do precisely what the async API is designed for, namely hiding
the fetch latency for slow or broken hosts in a cluster. Please don't
remove it just yet.
Noted, and this was never going to be something that would have happened
quickly.
Ok.
But if you do, please make libpcp sensibly thread-safe instead. I don't
know the current status, but the last time I looked, libpcp was not
threadsafe.
None of the various PCP libraries are thread safe. This was a conscious
decision right at the very beginning (not an accidental oversight).
Unless there is some magic automation that can be applied, I suspect
this would be a major exercise to implement (a) at all, and then (b)
across all of the current platforms.
For example, in libpcp.so
$ nm libpcp.so | grep '[ ][bB][ ]' | grep -v '\.[0-9][0-9]*$' | wc
-l
94
So, close to 100 statis or global variables that would have to "dealt
with" to make the code thread safe.
Aha. That's the situation I remember from my days digging around in
libpcp source, apparently it's not improved in the meantime. That's why
we did the async API in first place: it was less adventurous a change
than using threads.
I would however like to imagine a future where a PCP client program
(<cough/>pmchart<cough/>) can talk to multiple PMCDs using an
architecture with a fetch thread per PMCD and a user-interaction
thread. Having my UI lock up every time one of the cluster members wigs
out is just so 20th century.
and someone steps up
to help with the QA coverage of these routines I am strongly suggesting
that they be expunged at the next really major release, i.e. 4.0
I think extending the coverage of pcpqa is a good and worthy goal.
Any chance you could offer a code fragment that mimics your usage of the
async routines as a starting point for one or more QA apps?
I'll let Andrew do that, it's his code.
Aside: I'd be curious to see the results of your coverage study and to
know how you went about doing it.
OK ...
1. build libpcp.so from source
2. install GNUlocaldefs in the src directory containing
CFLAGS += -fprofile-arcs -ftest-coverage
LDLIBS += -lgcov
With a sufficiently recent gcc you should be able to do this in a
marginally less obscure manner, thusly
CFLAGS += --coverage
LDFLAGS += --coverage
3. touch pmns.c
4. make
5. over in the QA directory, export LD_LIBRARY_PATH=... path to the
directory containg the annotated libpcp.so
6. check -g pmns
7. back in the libpcp source directory run ggcov pmns.c and optically
grep for big chunks of redness
:D Oh good, it's working precisely as intended then.
If there is a flaw in this approach I'd appreciate hearing it,
especially from someone with a special interest in ggcov ... 8^)>
Heh :) No flaws. I was just curious to hear an example of real world usage.
ps I did need to perform a little surgery on ggcov-0.8 to make it build
and work with this week's toolchain in Ubuntu 9.10.
Please send me a patch, unless you've done the same as
http://ggcov.cvs.sourceforge.net/viewvc/ggcov/ggcov/src/cov_file.C?r1=1.78&r2=1.79
in which case it's already in 0.8.1.
--
Greg.
|