So far, our coroutine promise has implemented a so-called hot-start<\/i> coroutine, which is one that begins running as soon as it is created. Another model for coroutines is the so-called cold-start<\/i> coroutine, which is one that doesn’t start running until it is awaited.<\/p>\n
C# and JavaScript use the hot-start model: Creating the coroutine runs the coroutine body synchronously to its first suspension point, and only after the coroutine suspends for the first time is the coroutine returned to the caller. The usual usage pattern is to create the coroutine, and then go do other stuff while the coroutine is running, on the assumption that the synchronous portion of the coroutine is brief, and the expensive portion runs asynchronously. The hot-start model makes it easy to start multiple coroutines in parallel, and await the combined result.<\/p>\n
Python uses cold-start coroutines: The coroutine doesn’t start running until you await it. With cold-start coroutines, you need other machinery if you want to do work in parallel with the await, although that machinery could be made relative simply, like Python’s You could also create a hybrid model where the coroutine is cold-start, but can be manually started. Mind you, doing so reintroduces the state transitions you thought you had simplified away.<\/p>\n The C++ language doesn’t take a position on whether coroutines are hot-start or cold-start, or some hybrid of the two. It just provides the underlying infrastructure, and it’s up to you to decide what you want to build on top of it.<\/p>\n If we define the initial state as cold<\/i>, then our valid state transitions are as follows:<\/p>\n The nice thing about cold-start coroutines is that there are very few transitions, and none of them are contended. Furthermore, the state is completely implied by the actions of the task, so we don’t even need to keep track of it explicitly.<\/p>\n Here’s a sketch of the changes we can make to convert our hot-start coroutine promise to cold-start. Don’t incorporate these yet, for reasons we’ll see next time.<\/p>\n What makes this a cold-start coroutine is the fact that the The other state transitions are significantly simplified. Destroying the coroutine doesn’t need to check whether the coroutine is running, because it happens either before the coroutine even starts, or after it has completed, never when the coroutine is runinng. Completing the coroutine can always resume the The other wrinkle about cold-start coroutines is that the awaiter is responsible for starting it, which we do by calling You may have noticed an inefficiency here: If the coroutine completes synchronously,\u00b9 then we end up calling into the coroutine’s create_task<\/code> that runs a coroutine in an event loop. Cold-start coroutines have simpler bookkeeping since the running<\/i> and awaiting<\/i> states are identical, which makes a lot of state transitions impossible.<\/p>\n\n
\n\n
\n \n running<\/td>\n completed<\/td>\n abandoned<\/td>\n<\/tr>\n \n cold<\/td>\n Resume coroutine<\/td>\n \u00a0<\/td>\n Destroy promise<\/td>\n<\/tr>\n \n running<\/td>\n \u00a0<\/td>\n Resume awaiter<\/td>\n \u00a0<\/td>\n<\/tr>\n \n completed<\/td>\n \u00a0<\/td>\n \u00a0<\/td>\n Destroy promise<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n template<typename T>\r\n struct simple_promise_base\r\n {\r\n ...\r\n\r\n std::experimental::coroutine_handle<> m_waiting{ nullptr };<\/span>\r\n simple_promise_result_holder<T> m_holder;\r\n\r\n ...\r\n\r\n void abandon()\r\n {\r\n destroy();<\/span>\r\n }\r\n\r\n std::experimental::suspend_always<\/span> initial_suspend() noexcept\r\n {\r\n return {};\r\n }\r\n\r\n auto final_suspend() noexcept\r\n {\r\n struct awaiter : std::experimental::suspend_always\r\n {\r\n simple_promise_base& self;\r\n void await_suspend(\r\n std::experimental::coroutine_handle<>)\r\n const noexcept\r\n {\r\n self.m_waiting();<\/span>\r\n }\r\n };\r\n return awaiter{ {}, *this };\r\n }\r\n\r\n bool client_await_ready()\r\n {\r\n return false;<\/span>\r\n }\r\n\r\n auto client_await_suspend(\r\n std::experimental::coroutine_handle<> handle)\r\n {\r\n m_waiting = handle;\r\n as_handle().resume();<\/span>\r\n }\r\n\r\n ...\r\n };\r\n<\/pre>\ninitial_suspend_suspend_resume()<\/code>d.<\/p>\nm_waiting<\/code> coroutine, since the awaiter registers completion before resuming, so the resumption handle is known to be valid by this point.<\/p>\nresume()<\/code>.<\/p>\nresume()<\/code>, and the completion calls back into the awaiter’s resume()<\/code>. This accumulates stack frames, which is a problem for a coroutine that awaits other synchronously-completing coroutines in a loop, since each time through the loop uses another level of stack.<\/p>\n