Средства и методы разработки

Отменно закопано!  bialix уже намекал на подобное: http://caxapa.ru/339192.html В результате получаем смесь декларативной спецификации потоков и императивных кусков управления. Компактно описав потоки, мы попадаем на "размазанное по проекту" описание их поведения. Компактно описав что-нибудь другое, например, сообщения - мы размажем по проекту реакции на них. Это очевидно. Многие наступали на такое, в том числе и нокиа с сигналами в qt. bialix уже наработался с сообщениями между слоями реализации, и, как я понял, он сам не в восторге от результата. Остаются ещё недостатки. Один из них - отсутствие статического контроля на этапе компиляции. Целостность структурного предложения "PT_LABEL(pt); ... PT_GOTO(pt);" автоматически не проверяется. Это в одинаковой степени касается и указанного мной материала. Но есть существенное отличие. Функция не должна выполняться долго. Другим тоже чего-то пожевать надо. Но как в неё вернуться? Можно выставить (метку возврата)/(состояние автомата). И callback'ом назначить саму себя. Как правильно указал bialix, в этом случае каруселька не нужна ни внутри потока, ни снаружи. Но это ещё значит, что нужно сохранить контекст функции, а это может привести к data-races. Или не выходить, но использовать механизм распространения ситуаций, и вместо callback'ов использовать вложенные ситуации. Контекст уже на месте, с ним извратов не потребуется. Но где же здесь грабли? Как минимум, необходимо, чтобы выбранный слой реализации можно было представить в виде ациклического графа(дерева). Или леса таких деревьев, что возможно для произвольного графа. Как убить по таймауту - ещё не думал.