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 08:11:15 -0400
- Subject: Re: [pcp] suitability of PCP for event tracing
- References: <105152664.981101284508372475.JavaMail.root@mail-au.aconex.com> <4C90397B.1040305@evostor.com>
Hi -
On Wed, Sep 15, 2010 at 01:11:55PM +1000, Greg Banks wrote:
> [...]
> Personally I'm a big fan of void *closure pointers, see the pmLoop*()
> functions for examples.
>
> Guys, let's please not take the existing async API calls as an example
> of good design or as a precedent. I think they should be considered a
> short term expedient, and replaced with better design.
On the other hand, if the pmapi.h client-side model is likely to stay
single-threaded, then there is no need for passing back those
pointers: just use global variables.
> 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).
> 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.
- FChE