Lifecycle problems with `device_by_index` about nvml-wrapper HOT 3 CLOSED

Yeah, so due to the usage of lifetimes to track the relationships between the NVML instance and the Device structs obtained from it, it's not possible to store both the NVML instance and Device structs within the same object. (It creates a self-referential lifetime situation which isn't fun to deal with in Rust).

The best solution here is to initialize a global, static NVML instance and store it in a once_cell at program startup. You can then store devices obtained from that global instance within a struct. Here's an example:

use nvml_wrapper::{error::NvmlError, Device, NVML};
use once_cell::sync::Lazy;

static NVML_INSTANCE: Lazy<NVML> = Lazy::new(|| NVML::init().unwrap());

#[derive(Debug)]
struct NvmlDevices<'a> {
    devices: Vec<Device<'a>>,
}

impl<'a> NvmlDevices<'a> {
    pub fn new() -> Result<Self, NvmlError> {
        Ok(NvmlDevices {
            devices: (0..NVML_INSTANCE.device_count()?)
                .map(|i| NVML_INSTANCE.device_by_index(i))
                .collect::<Result<_, _>>()?,
        })
    }
}

fn main() {
    let devices = NvmlDevices::new();
    dbg!(&devices);
}

(I'm traveling and only have access to a mac right now, so I can't run that at the moment, but it compiles successfully for me.)

In the past I've thought about moving away from lifetimes and instead using Arcs to model the lifetime relationships (which would be easier to deal with and make your code example possible to write). Since this library doesn't provide performance-critical code, I think that might be the better path to go down. If I find time and interest I'll play around with implementing that in this library sometime in the future.

from nvml-wrapper.

@Cldfire I checked, it works.

I think the Arc implementation might be the way to go if the Device instances have to have a reference to the NVML instance.

Thank you.

from nvml-wrapper.

Awesome! Glad to hear that worked out for you.

from nvml-wrapper.