poll做的本质工作就是监测链条上前续Future的执行状态
不少博主在介绍Rust的Future等异步编程框架时都提到了Rust的Future采用poll模式，不过到底什么是poll模式却大多语焉不详，其实poll做的本质工作就是监测链条上前续Future的执行状态。
以上述情况为例，poll的方向是由response到request最后是socket，但是state和data的返回方向是完全返过来的，也就是说response通过poll来获取request的state，而request也同样通过poll来获取socket的state。
笔者还是这样的观点，程序员群体之所以觉得future机制难以理解，其关键在于思维模式被计算机的各种回调机制给束缚住了，而忘记了最简单直接的方式。在解决这个问题之前我们先来问一个问题，假如让我们自己设计一个类似于tokio这样的异步Future管理器，应该如何入手？
最直接也是最容易想到的方案就是事件循环，定期遍历整个事件队列，把状态是ready的事件通知给对应的处理程序，这也是我们常说的select方案；另外一种做法是在事件poll管理器中直接拿到处理程序的句柄，不再遍历整个事件队列，而是直接在中断处理响应中把通知发给对应处理进程，比如上述例子中实际是按照poll的链条传递的处理进程句柄的，这就是Poll模式。而基于poll设计的如tokio框架进行应用开发时，程序员根本不必关心整个消息传递，只需要用and_then、spawn等方法建立链条并让系统工作起来就可以了。
而epoll（多路复用）是基于poll的另一种高并发机制，这种机制可以监视多个描述符，一旦某个描述符状态变为就绪，能够通知对应的handler进行后续操作。笔者在前文《这位创造了Github冠军项目的老男人，堪称10倍程序员本尊》中曾经介绍过Tdengine的定时器，其中就有这种多路复用的思想。由于操作系统timer的处理程序还不支持epoll的多路复用，因此每注册一个timer就必须要启动一个线程进行处理，资源浪费严重，因此Tdengine自己实现了一个多路复用的timer，可以做到一个线程同时处理多个timer，这些细节上的精巧设计也是Tdengine封神的原因之一。