Frank Ch. Eigler wrote:
Hi -
On Thu, Sep 16, 2010 at 10:21:16AM +1000, Greg Banks wrote:
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.)
Which is hardly helpful if (e.g.) the server is not responding.
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?
I think that's an option, if you want to do push with a purely
single-threaded client which also responds to user input (like ^C) using
today's libpcp. Another option would be to add a function which does a
non-blocking poll on a context to check for any pending fetch results
and/or pushed data, and call that from the single app thread when poll()
reports activity on the context's fd. A third option would be to rely
on libpcp becoming threaded at some time in the future and add a
pmWatch-like API which does a cancellable blocking poll in a dedicated
thread.
(OTOH, are there
any open-source pcp clients that use the pmLoop* facility? git grep &
codesearch.google.com have no hits at all.)
Not AFAIK. The code it was created for lived only inside SGI. It might
still be alive, I don't know.
Or do you imagine a pure polling-based API all around, with buffering
latencies at the intermediate layers?
This could be made to work too.
--
Greg.
|