You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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?
The text was updated successfully, but these errors were encountered: