Tokio 0.2 发布及 1.0 版本路线图

我们非常激动地宣布 Tokio 0.2 发布。这是基于 async / await 和过去三年获得的经验对 Tokio 进行的彻底重构。

将以下内容添加到 Cargo.toml

tokio = { version = "0.2", features = ["full"] }

这是一个重大更新，因此几乎所有库的部件都发生了变化。以下重点介绍一些方面：

• 基于 async / await，提供卓越的人体工程学。

• 一个全新的、速度更快的调度器。

• 专注于使 Tokio 依赖项尽可能轻量化。

async / await

如果您之前使用过 Tokio，那么您一定熟悉编写异步 Rust 的“旧”方法... 这并不有趣。大多数人最终都手动编写状态机。这既繁琐又容易出错。

从 Rust 1.39 开始，async / await 在稳定通道上可用，Tokio 0.2 充分利用了它。在可能的情况下，Tokio 提供基于 async fn 的 API，通常模仿 std。

例如，从 TcpListener 接受套接字是通过异步 accept 函数完成的

let (mut socket, _peer_addr) = listener.accept().await?;

I/O 操作以 async 函数的形式提供

let n = socket.read(&mut buf).await?;

let n = socket.write(&buf).await?;

同样适用于 Tokio API 表面的其余部分。

启动 Tokio 运行时

现在可以使用过程宏来完成设置 Tokio 应用程序的入口点

#[tokio::main]
async fn main() {
    println!("Hello from Tokio!");
}

这将启动 Tokio 运行时以及为应用程序供电的所有必要基础设施。

一个新的调度器

新的 Tokio 配备了一个从头构建的调度器，以利用新的异步任务系统。它基于从 Tokio 0.1 获得的经验，以及投入到 其他 生态系统（如 Go、Erlang、Java 等）中的所有辛勤工作。

仍有改进空间，但使用 Hyper 进行的初步测试表明，在旧调度器和新调度器之间，宏级基准测试速度提高了 30% 以上。

您可以在此处阅读更多相关信息。

自从它登陆 master 分支以来，一些 Tokio 用户一直在尝试新的调度器，并在他们的应用程序中看到了一些非常令人印象深刻的真实改进。希望他们很快会写博客介绍这些改进！

轻量级的 Tokio 依赖项

用户对 Tokio 迄今为止最大的抱怨之一是依赖项的重量。从历史上看，添加对 Tokio 的依赖项会引入大量传递依赖项并增加编译时间。

例如，在我笔记本电脑上的“hello world” Tokio 0.1 应用程序会拉取 43 个 crate，并花费 50 秒进行编译（不包括下载依赖项所花费的时间）。

Tokio 从两个方面解决了这个问题。首先，大多数 Tokio 组件已折叠成一个单独的 crate：tokio，并且积极修剪了传递依赖项。其次，Tokio 组件已通过功能标志设置为 可选，而不是始终启用。仅仅拉取 tokio 依赖项只会为您提供一些 traits。

要开始使用 Tokio 0.2，您需要请求功能标志。full 功能标志包含所有内容，是入门的简单方法

tokio = { version = "0.2", features = ["full"] }

在我的笔记本电脑上，这会将 crate 的总数减少到 23 个。编译时间仅降至 40 秒。

当 Tokio 用户开始仅请求运行应用程序所需的组件时，真正的优势开始显现。要运行 TCP 回显服务器示例，需要 io-util、rt-threaded 和 tcp 功能标志。现在，Tokio 拉取 13 个 crate，编译需要 13 秒。

在修剪依赖项方面还有更多工作要做。Mio 0.7（进一步修剪依赖项）未包含在 Tokio 0.2 中。Tokio 0.3 将包含 Mio 0.7。

感谢

当然，如果没有我们出色的团队和为本次发布做出贡献的贡献者，这一切都不可能实现。许多个人提交了 PR，范围从文档修复到将整个 crate 迁移到 std::future::Future。我想特别提到一些名字，排名不分先后：

• @hawkw
• @ipetkov
• @jonhoo
• @LucioFranco
• @seanmonstar
• @taiki-e

预先感谢所有致力于 Mio 0.7 的人，遗憾的是它没有赶上本次发布，但很快就会发布！

• @dtacalau
• @kleimkuhler
• @PerfectLaugh
• @piscisaureus
• @Thomasdezeeuw

并非常感谢 Buoyant，Linkerd 的制造商（代理是用 Rust 编写的），他们赞助了大部分工作。

1.0 版本路线图

话虽如此，我们正在发布 0.2 版本。“为什么不是 1.0 版本？”这个问题已经被问过几次了。毕竟，Tokio 0.1 已经稳定了三年。简短的回答：因为时机未到。没有人比我们更希望发布 Tokio 1.0。但这也不是可以仓促完成的事情。

毕竟，async / await 仅在几周前才在稳定的 Rust 通道中发布。除了 Fuchsia 之外，还没有进行过重要的生产验证，而且这似乎是一个相当专业的用例。此版本的 Tokio 包含重要的新代码和带有功能标志的新策略。此外，仍然存在很大的开放性问题，例如对 AsyncRead 和 AsyncWrite 的拟议更改。

一旦 API 被证明可以处理真实世界的生产案例，Tokio 1.0 就会发布。

Tokio 1.0 将在 2020 年第三季度发布，并提供 LTS 支持

Tokio 1.0 版本将在 不晚于 2020 年第三季度发布。它还将提供“长期支持”保证

• 至少 5 年的维护。
• 在假设的 2.0 版本发布之前，至少 3 年。

当 Tokio 1.0 在 2020 年第三季度发布时，将保证持续支持、安全修复和关键错误修复，至少 到 2025 年第三季度。Tokio 2.0 将 至少 在 2023 年第三季度之前不会发布（尽管理想情况下永远不会发布 Tokio 2.0 版本）。

如何实现

虽然 Tokio 0.1 可能应该是一个 1.0 版本，但 Tokio 0.2 将是一个 真正的 0.2 版本。在 1.0 版本之前，每 2~3 个月将发布破坏性变更版本。这些更改将 远小于 从 0.1 -> 0.2 的更改。预计 1.0 版本看起来会很像 0.2 版本。

预计会发生什么变化

最大的变化将是 AsyncRead 和 AsyncWrite traits。根据过去 3 年获得的经验，有几个问题需要解决

• 能够 安全地 使用未初始化的内存作为读取缓冲区。
• 实用的向量化读取和向量化写入 API。

有几种策略可以解决这些问题。需要研究这些策略并验证解决方案。您可以查看 此评论 以获取问题的详细说明。

另一个重大变化是更新 Mio，它已经进行了很长时间。Mio 0.6 首次发布于近 4 年前，此后没有发生过破坏性更改。Mio 0.7 已经开发了一段时间。它包括对 Windows 支持的完全重写以及改进的 API。稍后将对此进行更详细的介绍。

最后，既然 API 开始稳定下来，我们将投入精力进行文档编写。Tokio 0.2 是在更新网站之前发布的，许多旧内容将不再相关。在未来几周内，预计会看到那里的更新。

所以，我们还有很多工作要做。我们希望您喜欢这个 0.2 版本，并期待您的反馈和帮助。