Comments 3
получается бинарное дерево может быть как-будто корутиной( из-за локализации обработки обьекта - тоесть его состояний ), в вашем случае просто обход идёт по списку, если я правильно понял
типо в случае дерева обьектов мы идём по дереву и просто обрабатываем обьекты по их логике, как раз этот пойнт меня привёл к мысли - дерево-корутина
но в этом случае если дерево-обьектов и рекурсия, то локальный кусок просто придётся оптимально выбрать, чтобы рекурсия не зашла слишком далеко наверно
как раз интересно получается - перечисление как тип обьекта-логика обработки, и просто прыгаем в рекурсию по дереву, идём по обьектам в дереве обрабатывая каждый обьект, неся его тип в нём
Честно говоря, не совсем понял как бинарное дерево может быть корутиной. Бинарное дерево - это иерархическая структура, данные в которой упорядочены. Например, двоичное дерево поиска. У всех узлов левого поддерева произвольного узла X значения ключей меньше либо равны, значению ключа узла X. У всех узлов правого поддерева X значения ключей больше, нежели значение ключа узла X. Корутина - это, грубо говоря, код, обрабатывающий некоторые данные. Она не является структурой данных. В статье речь идет о двух связном списке планирования для сопрограмм. Список последовательно просматривается с целью найти сопрограмму, которую можно запустить на выполнение или продолжить её выполнение. Такой упорядоченности как в бинарном дереве здесь нет. Просто проходим по всем элементам списка.
Могу подкинуть идею по поводу использования стека под каждую корутину (буду далее писать так потому что короче), давно уже витает реализовать подобное под МК, а там использовать классический менеджер памяти не комильфо. Первое - обеспечить постоянство расстояния стека от main до первого вызова корутины планировщиком. Второе - в момент первого прямого вызова корутины сохранить текущий указатель стека (типа базовое смещение). В момент разрыва синхронного выполнения (когда дальше через продолжение) - определить текущий указатель стека и вычисть с него базовое смещение, это даст размер фактического использования стека. Далее в дело вступает специальный менеджер памяти. Он может только выделять, но освобождать нет. Для каждой корутины предполагается потенциально фрагментированная кучка памяти. И вот корутина дошла до первого разрыва и просит 30 байт, предоставляется первый блок. Другая корутина после просит 40 байт, первая доходит до второго разрыва и там уже надо допом 50 байт, менеджер памяти выделяет за вторым блоком (40 байт) ещё блок в 50 байт, итого для первой корутины в сумме выделено 30 + 80 байт, но фрагментированной памяти. Но это не страшно так как пробежаться по связанному списку и скопировать стек в 80 байт в настоящий - относительно быстро. Таким образом как и с классическим стеком - появляется единственный дополнительный стек для корутин. Плюсы: 1. Теперь нужно думать только о размере одного стека. 2. Память максимально упакована и минимально используется. 3. Если прогнать все корутины по всем ветвям - легко определить сколько по факту надо. Минусы: 1. Стек копируется, от сюда просадка в производительности. Однако частенько корутины используются для прерываний на некоторую задержку или ожидание внешнего события или ввод/вывод. А это всё не нуждается в упоре на производительность. И так как сохраняется стек только локальных данных функции самой корутины - памяти много не нужно (если конечно на стеке не хранить жирные буферы).
Эволюция подходов к написанию корутин от Си до С++20. Часть 2. Переходим от бесстековых сопрограмм к стековым