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