Ответ на вопрос.

История вопроса

Ранние реализации корутин были состоянием, выделяя мегабайты фиксированной памяти стека на каждую смену контекста, что ограничивало количество одновременно выполняемых задач до тысяч. C++20 представил бессостоявшие корутины, выделяющие фреймы в куче, однако наивная рекурсивная компоновка по-прежнему подвергала риску переполнение стека, потому что асимметричная передача — возвращение void или bool из await_suspend — заставляла возобновляющий код вызывать resume(), создавая O(N) фреймы естественного стека вызовов. Симметричная передача была стандартизирована, чтобы разрешить корутине A напрямую возобновлять корутину B, отказываясь от фрейма стека A благодаря обязательной оптимизации последнего вызова.

Проблема

Когда корутина A вызывает co_await на корутине B, и B ожидает C, асимметричная передача требует, чтобы каждое выполнение resume() возвращалось к своему вызывающему объекту перед тем, как спуститься глубже. При глубине рекурсии N (например, при обходе 50,000+ узлов дерева) это истощает естественный стек, несмотря на то, что каждый фрейм корутины находится в куче, вызывая SIGSEGV или STATUS_STACK_OVERFLOW.

Решение

await_suspend должен возвращать std::coroutine_handle<Promise> (или std::coroutine_handle<>). Компилятор воспринимает это как оптимизацию последнего вызова: он уничтожает текущую запись активации и переходит непосредственно к точке возобновления целевого обработчика без роста стека вызовов. Этот механизм гарантирует выполнение с постоянной глубиной стека независимо от логической глубины вложения корутины.

struct Task {
    struct promise_type {
        Task get_return_object() { 
            return Task{std::coroutine_handle<promise_type>::from_promise(*this)}; 
        }
        std::suspend_always initial_suspend() { return {}; }
        std::suspend_always final_suspend() noexcept { return {}; }
        void return_void() {}
        void unhandled_exception() {}
    };
    std::coroutine_handle<> h;
};

struct SymmetricAwaiter {
    std::coroutine_handle<> target;
    bool await_ready() const noexcept { return false; }
    
    // Асимметрично (плохо): void await_suspend(std::coroutine_handle<>) { target.resume(); }
    
    // Симметрично (хорошо): Оптимизация последнего вызова
    std::coroutine_handle<> await_suspend(std::coroutine_handle<>) noexcept {
        return target; 
    }
    void await_resume() noexcept {}
};

Ситуация из жизни

Описание проблемы

При разработке высокочастотного торгового движка мы перешли от асинхронного ввода-вывода на основе обратных вызовов к C++20 корутинам для моделирования сложных деревьев ценообразования производных. Во время стресс-тестирования с портфелями, содержащими глубоко вложенные синтетические опционы (50,000+ уровней), система аварийно завершилась при переполнении стека, несмотря на использование фреймов корутин, выделяемых в куче. Виновником была первоначальная реализация await_suspend, возвращающая void, что вызывало пропорциональный рост стека при глубине модели ценообразования.

Разные рассматриваемые решения

Решение 1: Увеличить размер естественного стека через ulimit -s или флаги компоновщика.

Плюсы заключались в том, что это не требовало изменения кода и предоставляло немедленное облегчение во время тестирования. Минусов включали в себя нецелевое использование гигабайтов виртуальной памяти на поток, неспособность решить сценарии неограниченной рекурсии и создание проблем совместимости между Linux и Windows, где механизмы выделения стека значительно различаются.

Решение 2: Реализовать цикл исполнителя-трамплина, который не рекурсирует.

Плюсы заключались в том, что синтаксис корутины оставался неизменным, а управление стеком перемещалось в центральный событийный цикл. Минусы включали значительные задержки (сотни наносекунд на смену контекста из-за виртуальной диспетчеризации), усложнение кода в планировщике и потерю оптимизаций компилятора для выделения регистров по точкам приостановки.

Решение 3: Принять симметричную передачу, возвращая std::coroutine_handle из await_suspend.

Плюсы предоставили абстракцию без накладных расходов (идентичный ассемблер к ручным конечным автоматам), естественно обрабатывали неограниченную рекурсию без роста стека и сохраняли читаемый синтаксис корутин. Минусы требовали поддержки компилятора C++20 (изначально ограниченной на некоторых встроенных платформах) и усложняли отладку, поскольку трассировки стека были усечены из-за исключения последнего вызова.

Какое решение было выбрано и почему

Мы выбрали решение 3, потому что финансовые модели по своей сути требовали неограниченной глубины рекурсии для теоретических расчетов цен. Бюджет на микросекунды задержки не мог позволить себе накладные расходы на трамплирование, а ограничения по памяти запрещали массовое предварительное выделение стека. Симметричная передача предоставила единственное решение без затрат, которое было как правильным, так и эффективным.

Результат

Движок успешно обработал портфели с более чем 100,000 уровнями вложенности без аварий. Бенчмарки по задержке показали идентичную производительность ручных оптимизированных конечных автоматов на C, а использование памяти оставалось неизменным независимо от глубины рекурсии. Система работала в производственной среде 18 месяцев без сбоев, связанных со стеком.

Что кандидаты часто упускают

Почему возвращение void из await_suspend отличается от возвращения true с точки зрения времени приостановки фрейма корутины, и почему это важно для безопасности потоков?

Многие кандидаты предполагают, что void подразумевает немедленную приостановку и передачу управления. На самом деле, возврат void приостанавливает текущую корутину, но управление возвращается к вызывающему объекту resume(), который затем решает следующий шаг выполнения. Возврат true также приостанавливает, но критически важно, что void гарантирует, что корутина приостановлена до возврата await_suspend, в то время как точное время приостановки с bool может варьироваться в зависимости от реализации. Это различие имеет значение, потому что доступ к локальным переменным корутины после возврата await_suspend void (например, из другого потока) безопасен только после достижения точки приостановки. При симметричной передаче (возвращая обработчик) фрейм стека уничтожается сразу после возврата, делая локальные переменные мгновенно недоступными — кандидаты часто вводят гонки данных, обращаясь к захваченным переменным после инициирования симметричной передачи.

Как симметричная передача взаимодействует с обработкой исключений, когда целевая корутина выдает исключение, и почему это усложняет unhandled_exception в типе обещания?

Кандидаты часто упускают из виду, что симметричная передача обходит обычный откат стека через ожидающую корутину. Когда корутина A симметрично передает управление корутине B, и B выбрасывает исключение, исключение распространяется на unhandled_exception B. Однако фрейм стека A уже был заменен через оптимизацию последнего вызова, что означает, что A не может перехватить исключения от B, используя try/catch вокруг выражения co_await. Исключение на самом деле распространяется к первоначальному вызывающему A (возобновляющему), потенциально пропуская код очистки A, если только unhandled_exception в обещании A не управляет состоянием исключительно через выделенный в куче фрейм. Начинающие пользователи часто предполагают, что стеки RAII в A сработают, что приведет к утечкам ресурсов, когда исключения возникают в симметричных цепочках.

Какое значение имеет std::noop_coroutine() в симметричных цепочках передачи, и почему оно должно возвращаться, а не вектор по умолчанию подразумевать завершение?

Нулевая конструкция std::coroutine_handle является нулевым обработчиком, который вызывает неопределенное поведение, если его возобновить. Возвращая его из await_suspend, это указывает "ничего не возобновлять сейчас", оставляя текущую корутину приостановленной без преемника и потенциально повесив систему, если планировщик ожидает действительной продолжения. std::noop_coroutine() возвращает специальный синглтон-обработчик, который, когда его возобновляют, немедленно возвращает к своему вызывающему объекту. Это имеет решающее значение для завершения: когда корутина-лист завершает работу и хочет вернуть управление своему родителю без ручного возобновления, она возвращает std::noop_coroutine(). Это позволяет await_suspend родителя (который симметрично передал управление дочернему) получить действительное "продолжение", которое просто возвращает, эффективно завершая цепочку безопасно. Кандидаты путают нулевые обработчики с noop-обработчиками, что приводит к тонким зависаниям, когда система корутин ждет вечно по нулевому целевому возобновлению.