Rust 是否需要另⼀种“⾊彩”的 Future？ - 郭⼦兴

• 语言: 中文（简体）
• 格式: .pdf
• 来源: github.com/itfanr

摘要

文档讨论了Rust编程语言中Future类型在异步编程中的取消机制问题。作者提出，现有的Future在取消时可能产生未定义行为，因此需要引入另一种“颜色”的Future，以确保取消操作的安全性和确定性。新的Future类型旨在解决现有机制的局限性，特别是在处理有副作用的取消操作时提供更可靠的保证。

AI总结

## 文档总结

### 标题
**Rust 是否需要另一种“色彩”的 Future？**
作者：郭子兴，字节跳动服务框架团队研发工程师。

---

### 核心观点
1. **现有 Future 的问题**
- Rust 的 Future trait 在取消异步操作时，无法保证无副作用。
- 当 Future 被析构或取消时，可能引发未定义行为（如资源未正确释放或状态不一致）。

2. **“另一种色彩”的 Future 的必要性**
- 提出引入一种新的 Future 类型（称为“蓝色”Future），以解决现有 Future 在取消操作时的不安全问题。
- “蓝色”Future 的特点：
- 可以递归地处理取消信号，确保取消操作在所有嵌套的 Future 中正确传播。
- 避免取消操作导致的未定义行为，提升异步编程的安全性。

3. **基于 Poll 的异步模型**
- Rust 的异步编程基于 `Future` trait 的 `poll` 方法实现，但现有模型无法完全支持某些异步 IO 模型（如 `io-uring`）。
- 引入“蓝色”Future 可以更好地支持这些异步 IO 模型，并简化流程控制。

4. **折中方案**
- 基于字节跳动开源的异步驱动器 `monoio`，探索在现有 Future 模型中加入“蓝色”Future 的折中方案，以平衡兼容性和安全性。

---

### 关键信息
- **“红色”Future**：只能 await 其他“红色”Future，无法处理取消信号的递归响应。
- **“蓝色”Future**：可以 await“红色”和“蓝色”Future，确保取消信号的正确传播。
- **取消信号的传播**：取消 outer Future 时，必须同步取消 inner Future，否则可能导致资源泄漏或状态不一致。
- **RFC 和探索**：文档引用了多个 RFC 和相关资源，表明社区正在探索更安全的异步编程模型。

---

### 结论
Rust 的 Future 模型在取消操作和异步 IO 支持方面存在不足，引入“另一种色彩”的 Future 可以解决这些问题，提升异步编程的安全性和灵活性。通过结合现有工具链（如 `monoio`），可以在兼容性与安全性之间找到折中方案。