Re: [pcp] suitability of PCP for event tracing

[Greg Banks <gnb at evostor dot com>]

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.