On Mon, 15 Nov 2010 15:27:49 +1100, Ken McDonell wrote:
kenj> Not withstanding the current issues with the "supersize me" Darwin PMDA,
It's actually PMCD pmda, not Darwin.
kenj> if the memory pointed to by vp or cp from the pmAtomValue is dynamically
kenj> allocated (as an atomic unit, so not part of some larger allocation),
kenj> then valfmt of PM_VAL_SPTR is all that is needed. If it is part of
kenj> larger allocation then strcpy or malloc/memcpy and make the pmAtomValue
kenj> point to that, at which time you can free the underlying allocation.
The problem is that pmdaFetchCallback lacks the ability to communicate
with its callers - any PMDA which uses pmdaFetchCallback must track
the memory it had to allocate and deal with it on next call or stash
it somewhere where it can be re-used.
At the very least this kind of behaviour needs to be documented,
perhaps in pmdaFetch(3).
kenj> If it is more complicated than this, like one-shot-per-fetch allocations
kenj> that are filled and used to provide values for multiple metrics and/or
kenj> multiple instances, then I don't see how the PCP libraries can help and
kenj> it is up to the PMDA implementer to get it right (tm).
One way would be to add extra parameter to pmdaFetchCallback to
support flow of information back into the library. The other is to use
new PM_TYPE - library "knows" which metric it is dealing with and
could do the "right thing(tm)" with the memory.
max
|