This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [pcp] suitability of PCP for event tracing
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: Greg Banks <gnb at evostor dot com>
- Cc: "nathans at aconex dot com" <nathans at aconex dot com>, Ken McDonell <kenj at internode dot on dot net>, "systemtap at sources dot redhat dot com" <systemtap at sources dot redhat dot com>, "pcp at oss dot sgi dot com" <pcp at oss dot sgi dot com>
- Date: Wed, 15 Sep 2010 21:03:48 -0400
- Subject: Re: [pcp] suitability of PCP for event tracing
- References: <105152664.981101284508372475.JavaMail.root@mail-au.aconex.com> <4C90397B.1040305@evostor.com> <20100915121115.GF26765@redhat.com> <4C9162FC.1040402@evostor.com>
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