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


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.


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