fsm с gevent со своим (бесконечным) стеком вызовов

Question

Мне было интересно, как я могу определить конечный автомат, который имеет петли, используя гринлет в python, не вызывая stckoverflow.

С https://greenlet.readthedocs.org/en/latest/:

"" Гринлет "- это небольшая независимая псевдопотока. Думайте о ней как о небольшом стеке кадров; самый внешний (нижний) кадр - это исходная функция, которую вы вызвали, а самый внутренний кадр - это та, в которой в данный момент приостановлен зеленый экран. Вы работаете с гринлетами, создавая несколько таких стеков и выполняя прыжки между ними. Прыжки никогда не бывают неявными: гринлет должен выбрать переход к другому гринлету, в результате чего первый будет приостановлен, а второй возобновится там, где он был приостановлен. Прыжки между гринлетами называются "переключением"."

Я понимаю, что мне нужно будет изменить состояние и что у меня может быть FSM, подобный показанному на рисунке:

Как я могу гарантировать, что я не попаду в переполнение стека в таком случае? Поскольку гринлет дает мне только "небольшой стек кадров", я скептически отношусь к его использованию.

Существует ли здесь парадигма дизайна fsm, которая может помочь в возвращении к более ранним фреймам стека?

ТИА

Answer 1

Я прочитал немного больше о проблеме, и мне кажется, что я должен использовать Exception и try..except, что не приведет к вызову другой функции и, следовательно, позволит избежать переполнения стека. От: https://docs.python.org/2/faq/design.html

================================

Почему нет goto?

Вы можете использовать исключения для обеспечения "структурированного перехода", который работает даже при вызовах функций. Многие считают, что исключения могут удобно эмулировать все разумные варианты использования конструкций "go" или "goto" в C, Fortran и других языках.

Например:

метка класса: pass # объявить метку

try:
     ...
     if condition: raise label()  # goto label
     ...
except label:  # where to goto
     pass

=========================================