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

《Rust 是否需要另一种“颜色”的 Future？ - 郭子兴》 Rust 的异步编程基于 `Future` trait，允许用户通过自定义 `Future` 实现非阻塞 IO 或并发控制语义。然而，现有 `Future` 类型在取消异步操作时可能会导致未定义行为，尤其是在涉及 I/O 操作（如 `io-uring`）时，取消操作可能会产生副作用。为此，作者提出是否需要引入另一种“颜色”的 `Future` 类型，以提供更安全的取消机制。 ### 现状与问题 1. **现有 Future 的问题**： - 当 `Future` 未返回 `Poll::Ready` 时，其析构可能导致未定义行为。 - outer `Future` 的取消可能不会同步取消 inner `Future`，从而导致资源泄漏或其他错误。 2. **基于 `poll` 的 Future 和 I/O 操作**： - `io-uring` 等异步模型使 `Future` 的取消不再是“无副作用”的，这可能引发严重错误。 - 现有模型无法安全处理取消操作，尤其是在涉及并发和 IO 的场景中。 ### 解决方案 为解决上述问题，作者提出了两种可能的解决方案： 1. **引入“蓝色 Future”**： - “蓝色 Future”是一种新的 `Future` 类型，通过扩展 `Future` trait，增加 `poll_cancel` 方法。 - “蓝色 Future”可以安全处理取消操作，确保取消信号递归响应，避免未定义行为。 - 它支持同时等待“蓝色”和“红色”（现有）Future，以确保取消逻辑的完整性。 2. **基于 monoio 的折中方案**： - 字节跳动开源的 `monoio` 框架提供了一种折中方案，探索如何在现有生态下实现更安全的取消机制。 ### 结论 作者建议需要进一步探索“蓝色 Future”的引入，但也可以通过 `monoio` 等框架寻找中间方案，以解决当前异步编程中的取消安全问题。最终目标是为 Rust 的异步编程提供更高的安全性和一致性。