[pcp] suitability of PCP for event tracing

Greg Banks gnb@evostor.com
Thu Sep 16 00:21:00 GMT 2010


Frank Ch. Eigler wrote:
> Hi -
>
> On Wed, Sep 15, 2010 at 01:11:55PM +1000, Greg Banks wrote:
>   
>
>
>> Re Frank's API proposal: how does the client cancel a watch?
>>     
>
> In the pmWatch idea, control is handed to pmapi during the watch
> interval.  The client receives callbacks periodically, and at those
> times, it has the chance to cancel the watch.  This is what the
> poll/timeout intervals were for: to guarantee that the client will get
> some sort of callback no less frequently than the requested
> interval(s).
>   
Ok, so let me see if I understand the idea.  In this model the calling app

a) does not need to do anything else in the meanwhile, like run timers 
or respond to other network sockets or talk to the window system,

b) knows beforehand the complete set of pmids it needs to watch and can 
organise them into an array, to do a single global watch call,

c) knows how long it's main loop will take,

d) never needs to cancel a watch asynchronously, i.e. at any time except 
at the pre-nominated expiry or as the return value of a callback.

Also, what is the relationship between the pollInterval and the 
timeoutInterval values?  Which is larger than the other, and what are 
the semantics of specifying either or both as NULL or a zero struct 
timeval?  If pmWatch() is implemented by polling, does the polling 
happen immediately when called or one pollInterval later or at some 
other time?  Is any state kept between pmWatch() calls to make polls 
occur at regular times?  How is such an application supposed to handle 
gracefully receiving a signal?

As main loop designs go, I'm not very impressed.

>
>   
>> What thread is doing the servicing of the socket to PMCD, and if the
>> main app thread, when?
>>     
>
> It would be the single pmapi/app thread.
>
>
> If one puts the burden of buffering and client-state-keeping onto a
> PMDA, probably the same flavour of scheme can work there too, with
> single-threaded polling.
>
>
>   

I don't see any way of doing push without having some new behaviour in 
the PMDAs that support it, however I think it would be wise to strongly 
minimise and simplify the requirements on PMDAs.  We have a lot of 
PMDAs, they're written by all sorts of people, and testing them is not 
always easy.

-- 
Greg.



More information about the Systemtap mailing list