pcp
[Top] [All Lists]

Re: [pcp] suitability of PCP for event tracing

To: Max Matveev <makc@xxxxxxxxx>
Subject: Re: [pcp] suitability of PCP for event tracing
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Thu, 18 Nov 2010 14:04:25 +1100
Cc: pcp@xxxxxxxxxxx
In-reply-to: <19681.10763.616954.178026@xxxxxxxxxxxx>
References: <1565492777.26861289432902163.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxx> <148598811.26881289432947445.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxx> <19675.19189.501159.631040@xxxxxxxxxxxx> <1289778593.19153.891.camel@bozo-laptop> <1289795269.24913.10.camel@bozo> <19681.10763.616954.178026@xxxxxxxxxxxx>
Reply-to: kenj@xxxxxxxxxxxxxxxx
On Mon, 2010-11-15 at 23:39 +1100, Max Matveev wrote:
> ...
> 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.

OK Max, I have invested the effort in documenting how all of this really
works in http://oss.sgi.com/~kenj/pmda-malloc.html and I think I
(finally!) see your point.
PMDA_FETCH_DYNAMIC
I think there is a cleaner way to get what you want without breaking old
PMDAs or adding a new PM_TYPE (which is pretty pervasive) with the
proposal below to be added to the PMDA_INTERFACE_5 changes I've
alreadyPMDA_FETCH_DYNAMIC committed (returning PMDA_FETCH_DYNAMIC would
be the key) ...

        for metrics of type PM_TYPE_STRING or PM_TYPE_AGGREGATE, use
        PMDA_INTERFACE_5 or later, where the pmdaFetchCallBack method
        called from pmdaFetch() is able to return multiple state
        indications, namely
              * < 0 for an error
              * 0 (or PMDA_FETCH_NOVALUES) for no values
              * 1 (or PMDA_FETCH_STATIC) for a value that should not be
                freed
              * (or PMDA_FETCH_DYNAMIC) for a value which can be freed
                once __pmStuffValue() has been called
        
Max, would the address your concerns?

I need to think about what sane subset of the pmda-malloc.html document
should be included in the pmdaFetch(3) man page, where I agree we should
document how all this is supposed to work for the hapless PMDA
implementor.


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