|
| 1 | +# Scheduler Architecture |
| 2 | + |
| 3 | +This document describes the architectural differences between Boost.Asio and Corosio's coroutine scheduling mechanisms, and outlines the implementation approach for Corosio. |
| 4 | + |
| 5 | +## Overview |
| 6 | + |
| 7 | +Asio and Corosio take fundamentally different approaches to coroutine management: |
| 8 | + |
| 9 | +| Aspect | Asio | Corosio | |
| 10 | +|--------|------|---------| |
| 11 | +| Symmetric transfer | Simulated via `pump()` loop | Native language mechanism | |
| 12 | +| Type system | Closed (`asio::awaitable` only) | Open (`IoAwaitable` concept) | |
| 13 | +| `await_suspend` return | `void` | `coroutine_handle` | |
| 14 | +| I/O initiation timing | `after_suspend_fn_` callback | TBD | |
| 15 | + |
| 16 | +## Symmetric Transfer |
| 17 | + |
| 18 | +### The Problem |
| 19 | + |
| 20 | +When coroutine A awaits coroutine B, naive implementations create stack growth: |
| 21 | + |
| 22 | +``` |
| 23 | +A.resume() |
| 24 | + └─> B.resume() |
| 25 | + └─> C.resume() |
| 26 | + └─> ... // unbounded stack growth |
| 27 | +``` |
| 28 | + |
| 29 | +C++20 symmetric transfer solves this by allowing `await_suspend` to return a `coroutine_handle`, which the compiler tail-calls instead of returning to the caller. |
| 30 | + |
| 31 | +### Asio's Approach: Manual Simulation |
| 32 | + |
| 33 | +Asio's `await_suspend` returns `void`, forfeiting language-based symmetric transfer: |
| 34 | + |
| 35 | +```cpp |
| 36 | +// asio::awaitable - await_suspend returns void |
| 37 | +template <class U> |
| 38 | +void await_suspend( |
| 39 | + detail::coroutine_handle<detail::awaitable_frame<U, Executor>> h) |
| 40 | +{ |
| 41 | + frame_->push_frame(&h.promise()); // builds linked list |
| 42 | +} |
| 43 | +``` |
| 44 | +
|
| 45 | +Instead, Asio maintains a manual stack of frames and uses `pump()` to simulate symmetric transfer: |
| 46 | +
|
| 47 | +```cpp |
| 48 | +void pump() |
| 49 | +{ |
| 50 | + do |
| 51 | + bottom_of_stack_.frame_->top_of_stack_->resume(); |
| 52 | + while (bottom_of_stack_.frame_ && bottom_of_stack_.frame_->top_of_stack_); |
| 53 | + // ... |
| 54 | +} |
| 55 | +``` |
| 56 | + |
| 57 | +The `pump()` loop repeatedly calls `resume()` on the top frame until the stack empties or transfers to another thread. This achieves the same bounded-stack behavior but through explicit frame management. |
| 58 | + |
| 59 | +### Corosio's Approach: Native Symmetric Transfer |
| 60 | + |
| 61 | +Corosio's `task<T>` returns `coroutine_handle` from `await_suspend`, enabling compiler-optimized tail calls: |
| 62 | + |
| 63 | +```cpp |
| 64 | +// task<T>::await_suspend - returns coroutine_handle |
| 65 | +coro await_suspend(coro cont, executor_ref caller_ex, std::stop_token token) |
| 66 | +{ |
| 67 | + h_.promise().set_continuation(cont, caller_ex); |
| 68 | + h_.promise().set_executor(caller_ex); |
| 69 | + h_.promise().set_stop_token(token); |
| 70 | + return h_; // compiler tail-calls this handle |
| 71 | +} |
| 72 | +``` |
| 73 | +
|
| 74 | +Similarly, `final_suspend` returns the continuation handle: |
| 75 | +
|
| 76 | +```cpp |
| 77 | +auto final_suspend() noexcept |
| 78 | +{ |
| 79 | + struct awaiter |
| 80 | + { |
| 81 | + coro await_suspend(coro) const noexcept |
| 82 | + { |
| 83 | + return p_->complete(); // returns continuation |
| 84 | + } |
| 85 | + // ... |
| 86 | + }; |
| 87 | + return awaiter{this}; |
| 88 | +} |
| 89 | +``` |
| 90 | + |
| 91 | +This means task-to-task awaits have zero overhead beyond what the language provides. No pump loop needed for non-I/O transitions. |
| 92 | + |
| 93 | +## Type System |
| 94 | + |
| 95 | +### Asio's Closed System |
| 96 | + |
| 97 | +Asio's `await_suspend` only accepts handles to `awaitable_frame`: |
| 98 | + |
| 99 | +```cpp |
| 100 | +void await_suspend( |
| 101 | + detail::coroutine_handle<detail::awaitable_frame<U, Executor>> h) |
| 102 | +``` |
| 103 | +
|
| 104 | +This creates a closed type system where only `asio::awaitable<T>` coroutines can participate in I/O chains. User-defined coroutine types with different promise types cannot `co_await` an `asio::awaitable`. |
| 105 | +
|
| 106 | +### Corosio's Open System |
| 107 | +
|
| 108 | +Corosio uses the `IoAwaitable` concept, allowing any conforming type to participate: |
| 109 | +
|
| 110 | +```cpp |
| 111 | +template<class Awaitable> |
| 112 | +auto transform_awaitable(Awaitable&& a) |
| 113 | +{ |
| 114 | + using A = std::decay_t<Awaitable>; |
| 115 | + if constexpr (IoAwaitable<A>) |
| 116 | + { |
| 117 | + return transform_awaiter<Awaitable>{ |
| 118 | + std::forward<Awaitable>(a), this}; |
| 119 | + } |
| 120 | + // ... |
| 121 | +} |
| 122 | +``` |
| 123 | + |
| 124 | +The `await_suspend` signature accepts additional context parameters: |
| 125 | + |
| 126 | +```cpp |
| 127 | +coro await_suspend(coro cont, executor_ref caller_ex, std::stop_token token) |
| 128 | +``` |
| 129 | +
|
| 130 | +This design allows third-party awaitable types to integrate with Corosio's I/O system by satisfying the `IoAwaitable` concept. |
| 131 | +
|
| 132 | +## I/O Initiation Timing |
| 133 | +
|
| 134 | +### The Suspension Race Problem |
| 135 | +
|
| 136 | +A critical issue in coroutine-based I/O is ensuring the I/O operation isn't initiated until the coroutine is fully suspended. If the completion handler fires before suspension completes, the coroutine may be resumed while still in the middle of suspending—undefined behavior. |
| 137 | +
|
| 138 | +### Asio's Solution: `after_suspend_fn_` |
| 139 | +
|
| 140 | +Asio solves this with a deferred callback mechanism: |
| 141 | +
|
| 142 | +```cpp |
| 143 | +struct resume_context |
| 144 | +{ |
| 145 | + void (*after_suspend_fn_)(void*) = nullptr; |
| 146 | + void *after_suspend_arg_ = nullptr; |
| 147 | +}; |
| 148 | +
|
| 149 | +void resume() |
| 150 | +{ |
| 151 | + resume_context context; |
| 152 | + resume_context_ = &context; |
| 153 | + coro_.resume(); // coroutine runs until it suspends |
| 154 | + if (context.after_suspend_fn_) |
| 155 | + context.after_suspend_fn_(context.after_suspend_arg_); // NOW safe to initiate I/O |
| 156 | +} |
| 157 | +``` |
| 158 | + |
| 159 | +Within `await_suspend`, true I/O operations register their initiation function: |
| 160 | + |
| 161 | +```cpp |
| 162 | +// awaitable_async_op::await_suspend |
| 163 | +void await_suspend(coroutine_handle<void>) |
| 164 | +{ |
| 165 | + frame_->after_suspend( |
| 166 | + [](void* arg) |
| 167 | + { |
| 168 | + awaitable_async_op * self = static_cast<awaitable_async_op *>(arg); |
| 169 | + // Actually initiate the I/O operation here |
| 170 | + std::forward<Op&&>(self->op_)( |
| 171 | + handler_type(self->frame_->detach_thread(), self->result_)); |
| 172 | + }, this); |
| 173 | +} |
| 174 | +``` |
| 175 | +
|
| 176 | +Key distinction: |
| 177 | +- **Task-to-task awaits**: Use `push_frame()`, no `after_suspend_fn_` set |
| 178 | +- **True I/O awaits**: Set `after_suspend_fn_` to defer initiation |
| 179 | +
|
| 180 | +### Corosio's Approach |
| 181 | +
|
| 182 | +TBD - Document Corosio's mechanism for safe I/O initiation timing. |
| 183 | +
|
| 184 | +## Scheduler Implementation |
| 185 | +
|
| 186 | +TBD - Document: |
| 187 | +- Event loop design |
| 188 | +- Platform-specific backends (epoll, IOCP) |
| 189 | +- Threading model |
| 190 | +- Work stealing / distribution |
| 191 | +
|
| 192 | +## Implementation Plan |
| 193 | +
|
| 194 | +TBD - To be developed after gathering additional facts about: |
| 195 | +- Corosio's I/O initiation mechanism |
| 196 | +- Scheduler event loop design |
| 197 | +- Platform-specific details |
| 198 | +- Threading model |
0 commit comments