Re: [pcp] suitability of PCP for event tracing

[Ken McDonell <kenj at internode dot on dot net>]

On 16/09/2010 12:07 PM, Greg Banks wrote:
> Frank Ch. Eigler wrote:
> ...
> > Or do you imagine a pure polling-based API all around, with buffering
> > latencies at the intermediate layers?
> This could be made to work too.

I think we should pursue the discussion this approach a little further. 
 There is only one layer of buffering needed, at the PMDA.

So far, the obstacles to this approach would appear to be ...

1. Need buffer management and per-client state in the PMDA (actually it 
is per PMAPI context which is a little more complicated, but doable) ... 
I don't see either issue as a big deal, and together they are order of 
magnitude simpler than supporting the sort of asynchronous callbacks 
from PMCD that have been suggested.

2. Latency for event notification ... the client can control the polling 
interval (down to a few milliseconds demonstrably works), so I expect 
you'd be able to tune the latency to match the semantic demands.  If 
really low latency is needed then any TPC-based mechanism is probably 
not going to work well, and PCP may be the wrong tool for that space.

3. Each pmFetch may return none, one or many event records.  None is not 
a problem, but to support many we need to devise an encapsulated data 
aggregate within a pmResult that stores event parameters (including 
timestamps I suspect) as first order citizens in terms of pcp metadata 
... I don't think this is hard either.

I believe this approach would ...

a. allow event trace data to be intermixed with classical PCP data 
coming from PMCD to a PMAPI client

b. move the threadsafe PCP libraries work off into something that can be 
tackled independently (and probably should be done as the benefits are 
more general)

c. does not break any existing PMDAs or PMAPI clients

d. be doable in a very short time ... for instance wrapping an array of 
events inside a "special" data aggregate is simple and isolated, and 
there is already the basis for the required PMCD-PMDA interaction to 
ensure the context id is known to the PMDA, and the existing context 
cleanup code in PMCD provides the place to notify PMDAs that a context 
will no longer be requesting events.

So, can anyone mount a convincing argument that the requirements would 
demand changes to allow asynchronous behaviour between PMAPI clients 
<---> PMCD <---> PMDAs?

If not, I strongly suggest we work to flesh out the changes needed to 
make a variable length array of structured event records avaliable 
through the existing poll-based APIs.