-
Notifications
You must be signed in to change notification settings - Fork 525
Refactor SdkMeterProvider with Inner Structure for Better Lifecycle Control #1663
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
Conversation
It may not directly related to this PR but what's our general guideline on shutdown behavior when users call I see two possibility here:
I want to make sure we aligned on 1 |
Yes, agree on this in case of explicit In the case when |
Maybe I don't fully understand the semantics here, does that mean that all cloned instances of a signal provider give access to the same singleton resource? If so, then why implement |
Good question, and thanks for bringing this up.
let provider = super::SdkMeterProvider::builder()
.with_reader(reader.clone())
.build();
global::set_meter_provider(provider.clone());
....
// and later
provider.flush()
// and eventually
provider.shutdown() we can possibly use reference to the global meter provider (as this is the static instance), and thus restrict |
Fixes #1661
Design discussion issue (if applicable) #1661
Changes
SdkMeterProvider
by encapsulating its core functionality in a newSdkMeterProviderInner
structure.SdkMeterProviderInner
to ensure cleanup only occurs after the last reference is dropped.Drop
trait is triggered only when allSdkMeterProvider
clones are dropped.Merge requirement checklist
CHANGELOG.md
files updated for non-trivial, user-facing changes