当前位置: 首页 > 工具软件 > Tokio > 使用案例 >

Futures 和 Tokio 项目的前世今生

徐俊人
2023-12-01

用Rust搞网络相关,一般是绕不开这两个库的。这里尝试简单介绍一下它们的历史。

??~2016:原点

最初的时候。

首先futures是一套trait,也是异步操作的基本API。这个库是官方成员alexcrichton开发的。

然后是另一个叫做mio的库。mio是跨(桌面)平台的非阻塞IO API的封装,主要是 EventLoop实现(分别会使用epoll, kqueue, iocp)和其他一些Tcp、Udp的原语。这个库是carllerche开发的,他不是官方成员。但是这个项目是受到官方支持的。所以可以看作半官方项目。

好了,然后接下来就是futures和mio的整合了。因为futures只有trait,而mio是不依赖于futures的,所以需要一个库把它们整合在一起。这个库的名字叫futures_mio,是alexcrichton和carllerche两个人维护的。后来官方开始越来越重视这个,这个成为了官方支持的社区项目,可以看作是半官方项目,并把它列入到2017年的年度计划里,这是后话了。

2016~2017:Tokio 计划

2016年8月的时候,futures_mio 这个库也换了一个更响亮的名字,叫做tokio。tokio依赖futures和mio。tokio的计划是一整套异步支持的设施。这里面没有一个crate叫tokio。(tokio这个名字被预留了但是里面没有内容。)核心组件是tokio-core。并在上面有tokio-io, tokio-timer, tokio-proto等等。

tokio-core 里最重要的东西就是一个名叫Core的类型,它既是reactor又是executor。上层应用把用futures 接口表述的任务交给它,由它来调度执行。这是一个单线程的模型。在tokio-core的基础上,各种上层应用也纷纷尝试迁移过来获得异步支持,整个系统蓬勃地发展了起来。比如hyper(HTTP库),以及建筑在hyper之上的各种web框架。

试用了一段时间之后,大家一方面对它的本身的性能是满意的(参见几次techempower举办的 benchmark),另一方面在易用性上对tokio系统有很多不满意之处。首先它是那种基于回调的组合(参见使用老版本ES 的Nodejs),并且在调试的时候逻辑会跳来跳去。所以写起来,调试起来都不够好。其次,tokio-proto,这个tokio的上层设施(FramedCodec,Transport等),成为了彻底的鸡肋。

于是勤劳的alexcrichton又被安排以宏的形式实现了一个futures-await库,它可以让你标注一些async和await,以同步形式的代码来表述异步逻辑。这个大家应该都不陌生,其他语言很多也都有。【C++还没有,但是也快了。】实验进展的还是比较顺利的,不过这个必须要用nightly版本的rust编译器才能用。

积累了这些经验,在2017年末,官方又做了一个艰难的决定,搞了一个大新闻。

2017 Q4 ~2018 Q1

在2018年的分工里,勤劳的alexcrichton被安排去负责webassembly那一边了。futures这边的工作基本上移交给了官方新成立的net-wg小组。起到关键作用的是aturon和cramelj和withoutboats几位。

net组的工作重心从tokio转向了futures。然后做出了很多改动。

 

于是在新的思路下。官方开始倡导:中立的futures 提供executor、io;tokio提供IO紧密相关的reactor和对外接口这样的设计。

同时在tokio这一边,carl等人并不完全认同官方的思路。tokio这边希望继续使用tokio自行设计实现的executor、io等接口,并且后续可能还会根据使用和反馈继续调整。设计和实现上由于可以有更多的耦合所以会更有针对性。

这里还是存在一些分歧和讨论。

What's coming next

日前(4月)官方提出了futures 0.3 计划。将futures里的futures-await部分整合进入语言里成为语言特性。为了达到这一点,官方也需要整合一小部分futures到标准库里。

目前这个计划的RFC已经提出来了。大家正在对RFC内容进行热烈的讨论。

 

 类似资料: