Возвращение std::coroutine_handle из await_suspend позволяет использовать симметрическую передачу, форму гарантированной оптимизации хвостового вызова (TCO). Когда await_suspend возвращает void, среда выполнения корутины должна вернуться к своему вызывающему коду, прежде чем возобновить следующую корутину, создавая вложенный стек вызовов, который растет линейно с длиной цепочки. Возвращая дескриптор, компилятор испускает прямой переход (jmp инструкция) к пункту возобновления целевой корутины, повторно используя текущую запись активации и поддерживая постоянную глубину стека O(1) независимо от длины цепочки.
struct SymmetricTransfer { std::coroutine_handle<> next; // Оптимизировано по хвосту: нет роста стека std::coroutine_handle<> await_suspend(std::coroutine_handle<>) { return next; } void await_resume() {} bool await_ready() { return false; } };
Мы разработали движок обработки аудио в реальном времени для профессионального программного обеспечения по производству музыки. Система использовала C++20 корутины для представления конвейера из более чем 500 цифровых эффектов обработки сигналов (DSP) (фильтры, компрессоры, реверберация), соединенных между собой. Во время стресс-тестирования приложение выдавало переполнение стека при загрузке сложных эффектов, несмотря на то, что каждая отдельная корутина имела минимальное локальное состояние.
Решение 1: await_suspend с возвратом void и прямое возобновление Первоначальная реализация использовала void await_suspend(std::coroutine_handle<>) и вызывала next.resume() внутри. Этот подход предлагал интуитивный, последовательный поток кода и легкую отладку через стандартные трассировки стека. Однако каждый вызов resume() вложался в логику приостановки предыдущей корутины, потребляя примерно 16 КБ на каждом этапе и исчерпывая 8 МБ стека потока после лишь 500 этапов.
Решение 2: Рабочая очередь с асинхронным планированием Мы рассматривали возможность замены прямой цепочки на централизованную очередь задач, где каждая корутина отправляла следующий этап как элемент работы и немедленно приостанавливалась. Это гарантировало постоянное использование стека, преобразуя рекурсию в итерацию. Однако это приводило к значительному снижению производительности: динамическим аллокациям для узлов очереди, кэшевому соперничеству из-за конкуренции потоков и потере локальности кэша между этапами конвейера, что нарушало наши требования к задержке менее миллисекунды.
Решение 3: Симметрическая передача через coroutine_handle Мы переработали await_suspend так, чтобы он напрямую возвращал std::coroutine_handle следующего этапа. Это сигнализировало компилятору выполнить TCO, сокращая кадры стека. Решение сохранило нулевую стоимость абстракции корутин, одновременно обеспечивая использование памяти O(1). Основной риск заключался в управлении временем жизни: как только дескриптор был возвращен, текущая корутина приостанавливалась, и доступ к this или локальным переменным после точки возврата приводил к неопределенному поведению.
Выбранное решение и результат Мы выбрали Решение 3. После переработки конвейер успешно обрабатывал 512 последовательных эффектов, используя лишь 4 КБ пространства стека, устранив зависания и сохраняя детерминированную работу в реальном времени. Это изменение требовало тщательных проверок кода, чтобы гарантировать отсутствие логики после возврата в await_suspend, но привело к созданию надежной и масштабируемой архитектуры.
Почему симметрическая передача требует возвращения std::coroutine_handle, а не использования co_await для следующей корутины внутри await_suspend? Использование co_await внутри await_suspend требовало бы полной приостановки ожидающей корутины сначала, а затем последующего возобновления, что по сути вовлекло бы возвращение к среде выполнения и рост стека. Прямое возвращение дескриптора позволяет компилятору рассматривать возобновление как хвостовой вызов, в то время как co_await создает асимметричную точку приостановки, которая должна сохранить кадр вызывающего для последующего возобновления.
Как симметрическая передача влияет на безопасность исключений, если возобновленная корутина выбрасывает исключение до достижения своей финальной точки приостановки? Если корутина, к которой была передана симметрический контроль, выбрасывает исключение, оно разворачивается через фрейм await_suspend концептуально, но поскольку оригинальная корутина уже помечена как приостановленная, ее фрейм должен быть уничтожен во время разворачивания стека. Это требует от компилятора создавать сложные таблицы обработки исключений, которые уничтожают promise и захваченные параметры приостановленной корутины. Кандидаты часто упускают, что пользовательские аллокаторы promise_type должны правильно обрабатывать частичное построение, иначе существует риск двойного разрушения в процессе разворачивания исключений.
Что препятствует использованию симметрической передачи при реализации генератора, который возвращает значения из рекурсивной структуры данных? Генераторы полагаются на co_yield, чтобы вернуть управление вызывающему, сохраняя свое состояние. Симметрическая передача безусловно передает управление другой корутине и никогда не возвращается к оригинальному вызывающему, пока не завершится вся цепочка. Поэтому генераторы должны использовать асимметричную приостановку (возвращая void или true из await_suspend), чтобы позволить потребителю получить возвращенное значение и потенциально возобновить генератор позже, а не вынуждая необратимую передачу к другой корутине.