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
|