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] |
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.)
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.
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.)
This could be made to work too.Or do you imagine a pure polling-based API all around, with buffering latencies at the intermediate layers?
-- Greg.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |