А какой механизм расширения этого фрейма?

😢 ну вот почему такая вещь как корутины требует знания метафизики в программировании чтобы ей пользоваться?
Вот почему с потоками и их синхронизацией - достаточно просто: вот разумное количество способов создания/управления потоком, вот инструменты синхронизации, а вот проблемы при неверной синхронизации? Всё понятно, можно последовательно изучать и применять на практике, даже методом проб и ошибок.

Начиная  future/promise что-то стало ломаться. Вроде понятный механизм, но когда ты его реализовал и отладил, через какой-то промежуток времени этот код начинает вызывать смутные сомнения, а затем непонимание - что тут написано вообще? А если долго не пользовался, то и вообще забыл, вот что я тут должен использовать  future или promise, что куда передавать? И опять лезешь смотреть лекции/статьи.

С корутинами вообще странная ситуация - даже не понятно с чего начать и при этом не тянуть дополнительные либы.

речь не про стек, а про то на сколько его увеличивать.

Если будет большая глубина и большой размер фрейма, то много горутин просто израсходуют память.
Если сделать небольшой размер фрейма, то пользовательский код может не влезть.

Каждая стеклес корутина (С++) знает, сколько ей надо места, и такой проблемы нет.

Дима Вьюков на 1ой Гидре про split stack рассказывал https://www.youtube.com/watch?v=-K11rY57K7k

> С корутинами вообще странная ситуация - даже не понятно с чего начать и при этом не тянуть дополнительные либы.

Как раз про дополнительные либы понятно — в стандарт включили минимально необходимый конструктор, на базе которого каждый может собрать максимально эффективный комбайн под свои цели.

А дальше уже вопрос времени когда писатели различных библиотек выкатят искаробочные решения под наиболее востребованные сценарии.

Изросходуют память звучит как страшилка. userver вон используют в продакшене, и, если бы было бы все так плохо, наверное бы отказались?

ну вон была ситуация с фиберами в винде, их потом вообще перестали рекомендовать (есть в доке), так как они непредсказуемые

а страшилка не страшилка, но в самом го уже меняли размер фрейма же вроде. Там это сложно тюнить

А если без видео?
И наверное с терминологии стоит начать.
Под фреймом понимается просто сегмент стека или порция данных, ограниченная одним вызовом?

что значит непредсказуемые? непредсказуемым может быть код, который написал разработчик, стэкфул корутины тут не причем

значит, что для общего случая нет единого решения. Например, у нас нагрузка высокая и глубина стека большая, будет сильно потребляться память

общий случай… помоему С++ это всегда про дотюнивание и допиливание, иначе зачем всё это 🤷

Не каждая stackless корутина знает требуемый размер стэка, потому что есть рекурсивные корутины.

Более того stackful корутины реализованные в компиляторе тоже могут посчитать необходимый размер стэка в качестве оптимизации.

Не могу сказать что просмотрев презентацию понял.
Точнее, ничего прорывного не увидел.

Сегментированный стэк с аллокацией памяти на лету емнип(надо будет доклад ниже посмотреть тоже)
Тут есть лишь две проблемы у них
1) аллокация на лету
2) как выше отметили - может отожрать вообще все место

деталей я не знаю

плюс накладные расходы на обслуживание связного списка

аллоцирует на лету и просто цепляется как цепочка, да

плюс дыры будут в концах сегментов

но за счет ГЦ забывают проблемы с освобождением этой памяти после использования