Rust使用mio开发事件循环时可变与不可变借用冲突如何解决

1. 借用冲突的处理方案 #

你遇到的冲突是Rust借用检查的典型规则：不允许同时存在对同一资源的可变引用和不可变引用。这里handler是从self.handlers中借出的不可变引用，本质属于对self的部分不可变借用，自然无法同时获取&mut self。有三种常用的处理方式：

• 临时转移handler所有权：先将需要处理的handler从self.handlers中移除，取得所有权后再调用on_connected，处理完成后再插回handlers集合。这种方式无额外性能开销，是单线程事件循环最常用的方案：

for token in on_connected_tokens {
    // 从集合中取出handler，获取所有权，断开与self的借用关系
    let mut handler = self.handlers.remove(&token).unwrap();
    // 此时不存在对self的其他借用，可以正常传入可变引用
    handler.as_ref().on_connected(&mut self);
    // 处理完成后将handler插回集合
    self.handlers.insert(token, handler);
}

• 拆分结构体字段借用：不要给on_connected传入整个&mut EventLoop，而是仅传入handler需要操作的独立字段的可变引用，比如&mut Poll、&mut Events这类，Rust允许同时对结构体的不同字段分别做不可变和可变借用，只要不重叠即可。
• 内部可变性包装：如果handler本身不需要修改，可以用RefCell包裹handlers集合，运行时动态借出handler，只要保证调用on_connected的过程中不会再对该handler做可变借用即可，这种方式适合逻辑复杂、不方便转移所有权的场景。

2. Rust事件循环的惯用实现方案 #

基于mio开发事件循环的行业通用设计一般遵循以下规则：

• 分阶段执行：第一阶段只调用poll收集所有触发的事件、记录对应的Token，全程不修改事件循环的任何状态；第二阶段统一处理所有收集到的事件，避免边收集边修改导致的状态不一致和借用冲突。
• 避免给回调传入整个事件循环的可变引用：抽象独立的上下文结构体（比如EventContext），仅暴露回调允许使用的能力（注册新socket、提交异步任务、注销handler等），上下文内部通过内部可变性或原子操作访问事件循环的共享状态，从设计层面避免全局可变借用。
• 配合slab库存储handler：slab的内存分配特性天然适合用索引作为mio的Token，比HashMap更高效，也方便做资源回收。
• 上层开发优先使用成熟异步运行时：如果不是做底层组件开发，直接使用tokio这类已经封装好的异步 runtime 即可，其底层基于mio实现，已经处理了所有借用、调度、多线程兼容的问题，直接用async/await编写业务逻辑即可，不需要从零实现事件循环。

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