This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [pcp] suitability of PCP for event tracing


Hi -

On Thu, Sep 16, 2010 at 10:21:16AM +1000, Greg Banks wrote:
> [...]
> Ok, so let me see if I understand the idea.  In this model the calling app
> [...]

Yeah.

> 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?

There are some probably reasonable answers to these questions, if it
matters, but:

> How is such an application supposed to handle gracefully receiving a
> signal?

(The app would have to defer handling it till the next timeout
callback, stop the watch loop.)


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

Understood, but it wasn't meant as a *main* loop, only an extended
form of pmFetch that can return many results over time.  pmFetch
itself can take a relatively long amount of time (a network RPC), but
this hypothetical pmWatch would extend that time even more, so I see
your point.  I'm not sure how to proceed though.

Do you imagine an asynchronous callback for pmWatch-type functionality
being modeled as another pmLoopRegister* sibling?  (OTOH, are there
any open-source pcp clients that use the pmLoop* facility?  git grep &
codesearch.google.com have no hits at all.)

Or do you imagine a pure polling-based API all around, with buffering
latencies at the intermediate layers?


> [...]
> 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.  [...]

Definitely.

- FChE


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]