Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fate of ScopedMetrics #16

Open
jboynes opened this issue Jun 8, 2018 · 0 comments
Open

Fate of ScopedMetrics #16

jboynes opened this issue Jun 8, 2018 · 0 comments

Comments

@jboynes
Copy link
Contributor

jboynes commented Jun 8, 2018

TODO: throw this away, make frameworks handle it?

This provides a mechanism for associating a metric Context with the current Thread so that it does not need to be passed on every call. However, it relies on the ThreadContext library to do this. This is the type of thing a framework might use to tunnel metrics Context through application code so that it is available to framework libraries the application may use.

TODO: move fewer-parameter versions to MetricRecorder?

There are two aspects to what this class is doing. On one hand, it is providing a way for an emitted (the library) to retrieve the current metric Context so it can record a measurement. On the other hand, it is providing mechanisms for binding a Context to the current Thread before calling application code.

How about moving this the API class, but splitting the aspects between the metric Context and the Recorder?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant