如何设计可通过回调修改自身HashMap状态的Rust结构体？

我正在使用一个Rust库，它提供了创建对象和为事件绑定自定义回调的结构体与方法。每次回调触发时，我需要修改一个对象级的HashMap状态，但不清楚如何让回调安全地访问并修改这个HashMap。我尝试过将库对象和HashMap封装到新结构体中，但卡在了如何让回调操作结构体内部的HashMap这一步。

附上原始代码：

fn fileio_callback(record: &EventRecord, schema_locator: &SchemaLocator) {
    //...处理事件逻辑
    // 需要访问HashMap，但无法获取
    //...
}

struct EtwKernelFileTracker {
    trace: KernelTrace,
    fileobjects: HashMap<u64, String>,
}

impl EtwKernelFileTracker {
    fn new<T>(callback: T) -> EtwKernelFileTracker 
    where T: FnMut(&EventRecord, &SchemaLocator) + Send + Sync + 'static {    
        let file_provider = Provider::kernel(&KernelProvider::new(GUID::from("90cbdc39-4a3e-11d1-84f4-0000f80464e3"),EVENT_TRACE_FLAG_FILE_IO|EVENT_TRACE_FLAG_FILE_IO_INIT|EVENT_TRACE_FLAG_DISK_FILE_IO))
        .add_callback(callback)
        .build();

        let kernel_trace = KernelTrace::new()
        .named(String::from("file_io"))
        .enable(file_provider)
        .start_and_process()
        .unwrap();
        
        return EtwKernelFileTracker{trace: kernel_trace, fileobjects: HashMap::new()}
    }
} 

fn main() {
    let file_etw = EtwKernelFileTracker::new(fileio_callback);
    std::thread::sleep(Duration::new(10, 0));
}

解决方案 #

方案1：内部可变性+Arc共享状态（推荐） #

由于回调需要满足Send + Sync + 'static约束，且需要修改结构体的HashMap，我们可以用Arc<Mutex<HashMap<...>>>实现线程安全的状态共享。每个EtwKernelFileTracker实例持有独立的状态，回调通过克隆的Arc访问该状态。

修改后的代码示例：

use std::collections::HashMap;
use std::sync::{Arc, Mutex};
use std::time::Duration;

// 假设以下类型来自你使用的ETW库
struct EventRecord;
struct SchemaLocator;
struct KernelTrace;
struct Provider;
struct KernelProvider;
struct GUID;
const EVENT_TRACE_FLAG_FILE_IO: u32 = 0x00000002;
const EVENT_TRACE_FLAG_FILE_IO_INIT: u32 = 0x00000010;
const EVENT_TRACE_FLAG_DISK_FILE_IO: u32 = 0x00000020;

impl GUID {
    fn from(s: &str) -> Self { unimplemented!() }
}

impl KernelProvider {
    fn new(guid: GUID, flags: u32) -> Self { unimplemented!() }
}

impl Provider {
    fn kernel(kernel_provider: &KernelProvider) -> Self { unimplemented!() }
    fn add_callback<T>(self, callback: T) -> Self 
    where T: FnMut(&EventRecord, &SchemaLocator) + Send + Sync + 'static { unimplemented!() }
    fn build(self) -> Self { unimplemented!() }
}

impl KernelTrace {
    fn new() -> Self { unimplemented!() }
    fn named(self, name: String) -> Self { unimplemented!() }
    fn enable(self, provider: Provider) -> Self { unimplemented!() }
    fn start_and_process(self) -> Result<Self, ()> { Ok(self) }
}

struct EtwKernelFileTracker {
    trace: KernelTrace,
    fileobjects: Arc<Mutex<HashMap<u64, String>>>,
}

impl EtwKernelFileTracker {
    fn new() -> Self {    
        // 创建线程安全的HashMap，用Arc包裹以便共享
        let fileobjects = Arc::new(Mutex::new(HashMap::new()));
        // 克隆Arc给回调使用
        let callback_state = Arc::clone(&fileobjects);

        let file_provider = Provider::kernel(&KernelProvider::new(
            GUID::from("90cbdc39-4a3e-11d1-84f4-0000f80464e3"),
            EVENT_TRACE_FLAG_FILE_IO | EVENT_TRACE_FLAG_FILE_IO_INIT | EVENT_TRACE_FLAG_DISK_FILE_IO
        ))
        .add_callback(move |record: &EventRecord, schema_locator: &SchemaLocator| {
            // 处理事件逻辑...
            
            // 获取HashMap的可变引用，lock()保证线程安全
            let mut map = callback_state.lock().unwrap();
            // 修改HashMap，示例：插入键值对
            map.insert(12345, String::from("example_file_path"));
        })
        .build();

        let kernel_trace = KernelTrace::new()
            .named(String::from("file_io"))
            .enable(file_provider)
            .start_and_process()
            .unwrap();
        
        EtwKernelFileTracker { trace: kernel_trace, fileobjects }
    }
} 

fn main() {
    let file_etw = EtwKernelFileTracker::new();
    std::thread::sleep(Duration::new(10, 0));
}

核心逻辑：

• Arc允许状态被多个所有者（结构体实例和回调）共享，满足'static生命周期要求
• Mutex保证同一时间只有一个线程能修改HashMap，满足Send + Sync约束
• 回调用move闭包捕获克隆后的Arc，确保能访问到结构体的状态

方案2：全局静态状态（不推荐） #

如果不需要每个实例独立的状态，可以用全局静态变量配合内部可变性，但会导致状态耦合，无法区分多个实例的操作：

use lazy_static::lazy_static;
use std::sync::Mutex;
use std::collections::HashMap;

lazy_static! {
    static ref GLOBAL_FILE_OBJECTS: Mutex<HashMap<u64, String>> = Mutex::new(HashMap::new());
}

fn fileio_callback(record: &EventRecord, schema_locator: &SchemaLocator) {
    let mut map = GLOBAL_FILE_OBJECTS.lock().unwrap();
    // 修改全局HashMap
    map.insert(67890, String::from("global_file"));
}

缺点：全局状态会被所有EtwKernelFileTracker实例共享，不符合对象级状态的设计需求，仅适用于单实例场景。

方案3：自定义回调结构体（依赖库支持） #

如果库允许回调是实现特定trait的对象（而非仅Fn/FnMut闭包），可以将回调封装为EtwKernelFileTracker的内部结构体，通过Arc<Mutex<Self>>访问状态。但这种方式通用性较低，取决于库的回调设计。

内容的提问来源于stack exchange，提问作者asxce