The funny thing is async/await is actually fairly easy to understand (IMO a bit finicky to use, partly because manually managing resources with that control flow is tricky, partly because of bugs that need workarounds pre-1.0), but the docs aren't stellar, so you have to experiment a bit or ask the community how certain code is supposed to be have.
As one example, here's a description of "suspend" straight from the docs:
> At any point, a function may suspend itself. This causes control flow to return to the callsite (in the case of the first suspension), or resumer (in the case of subsequent suspensions).
That description isn't quite right though. Control flow returns up the call-stack to the most recently executed async-aware bit of code. In particular, that'll either be the most recent _async_ callsite or whoever last resumed this function. It's precisely those semantics which enable one to write a nice event loop API, but the docs tell you something different.
Saying that aloud, I should probably just file a PR and fix that. Off to $WORK soon, but that sounds like a good this-evening problem if nobody grabs it first.
As one example, here's a description of "suspend" straight from the docs:
> At any point, a function may suspend itself. This causes control flow to return to the callsite (in the case of the first suspension), or resumer (in the case of subsequent suspensions).
That description isn't quite right though. Control flow returns up the call-stack to the most recently executed async-aware bit of code. In particular, that'll either be the most recent _async_ callsite or whoever last resumed this function. It's precisely those semantics which enable one to write a nice event loop API, but the docs tell you something different.
Saying that aloud, I should probably just file a PR and fix that. Off to $WORK soon, but that sounds like a good this-evening problem if nobody grabs it first.