nathans wrote:
> [...] One relatively straight forward approach to improving things
> would be to allow clients to (optionally) change the container
> associated with a given context at any time after context creation.
For highly asynchronous continuation-based systems like
vector/javascript, this newly stateful pmwebapi context# would be a
complication. It means that operations on a shared context would have
to be precluded or carefully sequentialized, since the (new)
change-context and (old) normal-fetch operations must now be
atomically paired.
At the moment, the same context# can be reused concurrently (ignoring
indom profiles). This change may require vector to use numerous
pmwebapi contexts (for concurrency control), in which case we would
not really save anything.
> [...] I've looked into extending that idea so that it becomes a
> pmStore(3)-able metric. [...]
While pmStore exists, its current access control mechanism
(/etc/pcp/pmcd.conf) is such a blunt instrument that IMHO we
need to revisit that before relying on it further. It's not
that the pure context self-modification is risky - it's that
this mechanism would encourage us to open (allow "*": all)
up pmcd.conf, which would open up all the other pmdas.
Have you considered extending PMAPI formally, maybe adding
an attribute-string spec to pmFetch (which could include the
container=XXXX stuff)?
- FChE
|