[推荐] 最近学写 async/await 被 Rust 毒打的经验

不要自作主张地返回 Poll::Pending。

只有在你调用的方法返回了 Poll::Pending 时，才能够返回 Poll::Pending。 不然，也许程序会通过编译，但运行结果不会是你想要的。如果你的 Future 只是对现有 Future 的简单包装，一般不会犯这种错误，但情况复杂了，可能会忘。

我们日常使用的 Future，如 TcpStream/channel/timer 之类，其实是与底层的 reactor 相关联的，它们在返回 Poll::Pending 的时候，同时会在 reactor 注册事件，所以才会收到通知，最终 wakeup 相应的 Future。我们自己随便返回 Poll::Pending 的时候，显然不会收到通知的。

可能是由于 Rust 选择的抽象方式的原因，我们一般只关注 Future 本身，忽略与 reactor 的联系。其他语言的话，貌似 reactor 或者叫 event loop 才是最核心的概念。

async/await 是高层 primitive，而 Poll 是低层 primitive。高层使用低层，很方便，反过来，比较麻烦，得避免。

有个感觉，async/await 普及开来的话，Poll 只有较底层的库才关心，日常只会与 async/await 打交道。 (另外，我们就算与 Poll 打交道时，其实几乎也不关心 Context 或者 Waker，感觉它们更底层。)

await 与 tokio::sync::Mutex 一起使用，需要注意死锁问题。

从某种意义上说 await 也是有「锁」的语义，至少都需要「等待」。只是 Mutex 等待别人 unlock，而 await 在等待事件发生。(tokio::sync::Mutext 的 lock() 方法返回的就是 Future，需要你 await 的。)

举个例子，lock 之后，然后 await。如果被 await 的 Future，也需要 lock，然后才能返回 Poll::Ready。这时实际上就死锁了，两个 Future 会无限等待下去。

所以呢，不要认为，我反正只用了一把锁，所以死锁是不可能的。（推