>If the deepest call yields, what code is executed? Does it “jump back” to the top ala “longjmp” or it needs to return back up the stack frame by frame?
It goes back frame-by-frame. Yielding (ie returning `Poll::Pending`) is essentially returning "I'm not ready yet" and it's possible the parent future wants to do something else in that case.
The simplest case is a future that wraps a collection of futures and resolves to the value of the first one that resolves. In this case it would cycle through each child future and only return `Pending` if all of them return `Pending`.
Another case is that of a timeout future that wraps another future - it would resolve to `Err(TimedOut)` if the wrapped future returns `Pending` for too long.
>And what happens when it resumes execution?
The top-most future of the task is all the executor knows about, so the executor has no choice but to start from there.
There have been comments in this HN thread that this implementation of continuations based on futures is supposedly more performant than a stack-pointer switching one (like green threads). Can you elaborate on how? It looks to me that it should instead be slower (and even much slower if the stack depth is deep).
It cannot be more "performant". The design of demand-driven futures is used because it allows "zero-cost futures". Specifically poll()ing the Future is required to drive it, and drop()ping the Future frees its resources. Both of these require another future or the executor itself to be the parent of every future, rather than the future driving itself.
But also the performance is not likely something to worry about. I've never measured it myself but I do know aturon posted that he could not find any measurable effect of having deep future stacks. It is noticeable in the sense that a big enough stack may exceed your OS's limit (especially on Windows where the main thread defaults to a 1MiB stack).
It goes back frame-by-frame. Yielding (ie returning `Poll::Pending`) is essentially returning "I'm not ready yet" and it's possible the parent future wants to do something else in that case.
The simplest case is a future that wraps a collection of futures and resolves to the value of the first one that resolves. In this case it would cycle through each child future and only return `Pending` if all of them return `Pending`.
Another case is that of a timeout future that wraps another future - it would resolve to `Err(TimedOut)` if the wrapped future returns `Pending` for too long.
>And what happens when it resumes execution?
The top-most future of the task is all the executor knows about, so the executor has no choice but to start from there.