'static metrics::set_recorder(..) and metrics::Recorder trait

[BMorinDrifter]

Why does metrics::set_recorder input a &'static dyn Recorder, however the static lifetime is demoted when calling into the methods for the trait metrics::Recorder?

Couldn't the methods (describe_counter, register_counter, etc.) input a &'static self to simplify their implementation as they would not have to work around the metrics handles passed into metrics::XXX::from_arc(...) potentially outliving the recorder?

Apologies if this is a silly question, I'm building a CloudWatch embedded metrics recorder intended for AWS Lambda functions and worked around this with an unsafe cast back to 'static so I could implement my Counters and Gauges as a vector of AtomicU64 allocated/leaked at initialization.

[tobz]

They could be changed to take &'static self, but that would prevent us from making changes in the future that dealt with non-'static recorders, such as if we wanted to add the ability to temporarily override the global recorder for the duration of a closure, etc.

Generally speaking, there's hardly ever an issue with the lifetime of the &self reference because the fact it's immutable is the bigger problem, requiring synchronization to handle updating internal state and so on.

It strikes me that if you're already leaking a bunch of atomics in a way to get static references to them, then you shouldn't have any problems: you can create an Arc<&'static T> where T is CounterFn or GaugeFn, and so on, and use that to construct the respective metric handle type. The whole point of it requiring Arc<T>, after all, is precisely so that metric handles don't need to always be 'static, otherwise there would be no way for metrics to ever be able to be expired and it would all just turn into one big memory leak over time.

[BMorinDrifter]

Is there a better way to do this? The constraint that I will only have X counters + gauges and X is known at init is fine.

pub struct Collector {
    // Only allocated once, never re-sized, parent is leaked/static
    simple_counters: Vec<AtomicU64>,
    // Stuff that's only touched by the describe methods and flushing counters
    state: Mutex<CollectorState>,
    config: CollectorConfig,
}

struct CounterHandle {
    value: &'static AtomicU64,
}

impl metrics::CounterFn for CounterHandle {
    fn increment(&self, amount: u64) {
        self.value.fetch_add(amount, Ordering::Relaxed);
    }

    fn absolute(&self, new_value: u64) {
        self.value.store(new_value, Ordering::Relaxed);
    }
}

// Unsafe fun to get a static lifetime out of &self later....
fn static_counter(counter: &AtomicU64) -> &'static AtomicU64 {
    unsafe { std::mem::transmute::<&AtomicU64, &'static AtomicU64>(counter) }
}

fn register_counter(&self, key: &metrics::Key) -> metrics::Counter {
     let mut state = self.state.lock().unwrap();

     // ...I probably should check for a key we already have here...

     if state.simple_metric_info.len() == state.simple_metric_info.capacity() {
        panic!("Out of metric counters, increase max_counters");
     }

     let counter = Arc::new(CounterHandle {
        value: static_counter(&self.simple_counters[state.simple_metric_info.len()]),
     });

     let metric_info = SimpleMetricInfo {
        key: key.clone(),
        is_gague: false,
        unit: None,
     };

     state.simple_metric_info.push(metric_info);

     metrics::Counter::from_arc(counter)
}

[tobz]

Just store Vec<Arc<AtomicU64>> and get a clone of them when creating the handles in register_counter, etc. There's no need to do anything with &'static.

[BMorinDrifter]

I found the CounterFn and GaugeFn implementations for AtomicU64. From there things fell into place without the unsafe code.

Thanks so much for taking the time to answer my question, much appreciated.

[BMorinDrifter]

Crate published
https://crates.io/crates/metrics_cloudwatch_embedded