Hi -
I wrote:
> [...]
> > >>- overload pmCreateFetchGroup() to take either a context, or a
> > >>source string, (defaulting to "local:"). And then provide method to
> > >>return the context for use by other pmapi functions.
> > [...]
> >
> > well it saves one or two lines or code (no big deal), but perhaps
> > more importantly it reinforces one fg per context.
>
> Hm, I'm starting to like the sound of that. It would make it less
> likely to accidentally misuse (share) the pmfg-dedicated contexts -
> and moot multithreading / sharing-detection-error concerns.
I've started to dislike the sound of that a bit, having started
prototyping it. Sure, the scheme works OK for those pmapi clients
that have a straightforward one-context fetchgroup-setup
fetch-fetch-fetch loop ...
But for pmclient, we have a get_ncpu() function that does a one-shot
lookup/fetch of just one metric; and then another function that does a
looped lookup/fetch of other metrics.
Under the status quo, these can reuse the same initialized context,
since they create nonconflicting (sequential) temporary fetchgroups on
top of it. Under the proposed scheme where a fetchgroup-create does a
pmNewContext, we can't share the initialization work between the
fetchgroups; all that stuff in main() would have to be copied, or a
single longlived fetchgroup would have to be used (in which case
get_ncpu can't use local variables as destinations), ... or something
else similarly clumsyish.
- FChE
|