Tokio Reform 已发布,通往 0.2 的道路
2018 年 2 月 7 日
大家好!
我很高兴地宣布,今天,改革 RFC 中提出的更改已作为 tokio
0.1 发布到 crates.io。
主要的更改是
-
添加一个默认全局事件循环,从而在绝大多数情况下无需设置和管理您自己的事件循环。
-
将所有任务执行功能与 Tokio 解耦。
新的全局事件循环
直到今天,创建事件循环还是一个手动过程。即使绝大多数 Tokio 用户都会设置 reactor 来做同样的事情,但每个人都必须每次都这样做。这部分是由于在 Tokio reactor 的线程上或从另一个线程(如线程池)运行代码之间存在显着差异。
允许 Tokio 改革更改的关键见解是,Tokio reactor 实际上不必是执行器。换句话说,在这些更改之前,Tokio reactor 既会驱动 I/O 资源又会管理执行用户提交的任务。
现在,Tokio 提供了一个 reactor 来驱动 I/O 资源(如 TcpStream
和 UdpSocket
),与任务执行器分开。这意味着可以很容易地从任何线程创建 Tokio 支持的网络类型,从而可以轻松创建单线程或多线程 Tokio 支持的应用程序。
对于任务执行,Tokio 提供了 current_thread
执行器,其行为类似于内置的 tokio-core 执行器。计划最终将此执行器移入 futures
crate,但目前它由 Tokio 直接提供。
通往 0.2 的道路
Tokio 改革更改已作为 0.1 发布。依赖项(tokio-io
、 futures
、 mio
等)的版本尚未递增。这允许 tokio
crate 以最小的生态系统中断发布。
计划是在提交这些更改之前,先让此版本中的更改得到一些使用。任何需要重大更改的修复都将能够与发布到所有其他 crates 的版本同时完成。目标是在 6-8 周内实现这一目标。因此,请尝试今天发布的更改并提供反馈。
快速迭代
这仅仅是个开始。Tokio 有着雄心勃勃的目标,即提供额外的功能,以便在 Rust 中构建异步 I/O 应用程序时获得出色的“开箱即用”体验。
为了在不引起不必要的生态系统中断的情况下尽快实现这些目标,我们将采取一些步骤。
首先,类似于 futures
0.2 版本,tokio
crate 将被转换为更像一个外观模式。特性和类型将被分解为多个子 crate,并由 tokio
重新导出。应用程序作者将能够直接依赖 tokio
,而库作者将选择他们希望用作库一部分的特定 Tokio 组件。
每个子 crate 都将清楚地表明其稳定性级别。显然,futures 0.2 版本即将进行重大更改,但在此之后,基本构建块的目标是保持至少一年的稳定。更具实验性的 crates 将保留以更快的速度发布重大更改的权利。
这意味着 tokio
crate 本身将能够以更快的速度迭代,同时库生态系统保持稳定。
0.2 之前的时期也将是一个实验时期。其他功能将以实验性质添加到 Tokio 中。在 0.2 版本发布之前,将发布 RFC,涵盖我们希望包含在该版本中的功能。
开放性问题
剩下的一个问题是如何处理 tokio-proto
。它作为初始 Tokio 版本的一部分发布。从那时起,重点已经转移,并且该 crate 没有受到足够的关注。
我在这里发布了一个 issue 讨论如何处理该 crate here
展望未来
请尝试今天发布的更改。再次强调,接下来的几个月是在我们提交下一个版本之前的实验期。所以,现在是尝试并提供反馈的时候了。
在此期间,我们将整合这项工作,以在 Tower 中构建更高级别的原语,这受到 Conduit 项目的生产运营需求的驱动。