Hacker News Reader

The model is very similar to how epoll works. The executor does not poll futures in a loop. Between polls, the executor waits for a readiness notification.

If `Future::poll` returns Pending, once it becomes ready to do more work, it notifies the executor, the executor then schedules the future to be polled again.

It doesn't poll all the time. The context parameter contains a walker, and you have to tell the executor to wake you up using that waker when you are ready to continue.

I suspect that a big part of the design of this api (and why it take time) was exactly to be as performant as possible.

The compiler desugar the async/await to state machines and that is melted away by regular means. Also, the quality of the runtime elected must take some credit.