Closed tyrone-wu closed 4 months ago
Actually #154 solves the first part of my usecase since I can just stitch together the registries of my sub-systems. π
The only part left is just a way to unregister a metric family.
Alright, so I have sort of a working progress. Removing it from metrics list is pretty straightforward, however, there's the issue how to approach cleaning up leftover Arc
references to Family
.
My initial idea was to have priv_register()
return a Weak<dyn Metric>
, however I'm learning that adding a Clone
trait bound to Metric
doesn't make it object-safe. I won't lie, I'm not rusty enough to completely understand all the ins and outs of these internal things. π΅
Hello! π
I have a usecase that can be split into 2 separate issues (let me know and I can split it π), but I'll have them here for now to describe my overall usecase.
I'm creating a library with sub-systems that each manage their own
registry
, and are logically grouped together to form a rootregistry
. For each sub-system, they hold some state that is used to register/unregister metric families.~For the first part of my usecase, I've tried using
sub_registry_with_prefix()
and theCollector
trait, however, they both have these limitations:~sub_registry_with_prefix()
, since it returns a reference, I can only operate on thesub_registry
within the same scope when it's first created.~Collector
trait, the collector struct can't be modified after it's registered.~~If possible, I'd like for my sub-systems to either "own" their
sub_registry
so that they can individually manage their own metrics. Perhaps something similar toFamily
, soVec<Rc<RwLock<Registry>>>
orVec<Rc<RefCell<Registry>>>
forsub_registries
?~For the second part of my usecase, this is simply adding a way to unregister metric families, something like
Registry::unregister(&mut self, name: &str, unit: Option<Unit>)
?If these changes make sense to be apart of the library, I'd be happy to open a PR for these. π± And sorry if what I described above is messy, I can elaborate if need be.