Futures and Segmented Stacks
The point of using async IO over blocking IO is that it gives the user program more control over handling IO, on the premise that the user program can use resources more effectively than the kernel can. In part, this is because of the inherent cost of context switching between the userspace and the kernel, but in part it is also because the user program can be written with more specific understanding of its exact requirements.
Whether using async “tasks” or blocking “threads,” fundamentally the unit of work needs space to store its immediate state as work is done. For a “task,” as in Rust’s futures model, this is the state stored in the future object that is being polled to completion. For a “thread,” as in OS threads or Go’s goroutines, this is the thread’s stack. Let’s look at the implementation of stacks in more detail, so we can see better how futures can improve on them.
A stack is a defined space in which the executing unit of work can store its state. It’s implemented as a stack data structure: more stackframes are pushed to the stack with each function, and popped from it as they conclude. The interesting question comes with this issue: what do you do when the stack runs out of space? There are three basic options:
