Кстати, большей частью из-за указанных вами недостатков, упомянутый мной С. Федоров и взялся написать свою библиотеку FSM. Шаблоны это, конечно, нитроглицерин — малейшая неострожность, и компилятор бомбанет, мало не покажется) Но до чего захватывающая штука! В азарте сложно держать баланс между реальными требованиями задачи и использованием шаблонов ради любви к шаблонам.
Дело говорите! Но статья преимущественно о том, как взять себя за яйца постараться и повторить в концепте/эксперименте задумку крутого чувака из Яндекса. Безусловно до кода, готового к продакшену очень далеко, но я потихоньку допиливаю…
Спасибо за комментарий и наводки, посмотрю!
Когда думал об очереди, держал в голове примерно такой сценарий.
Мы находимся в стейте, где, скажем, отрисовываем что-то на экране. Из этого стэйта мы можем перейти в два других по двум разным эвентам. В это время из прерываний нам прилетают 4 эвента, два «наших» с разными приоритетами, и два — для следующих стэйтов. Как тут обойтись (и можно ли) без очереди я пока не знаю. Можно, конечно, возразить что архитектурно не нужно допускать описанных ситуаций, но в том и смысл всяческих диспетчеров и атоматов, чтобы обеспечить гибкость в разработке.
взять себя за яйцапостараться и повторить в концепте/эксперименте задумку крутого чувака из Яндекса. Безусловно до кода, готового к продакшену очень далеко, но я потихоньку допиливаю…Когда думал об очереди, держал в голове примерно такой сценарий.
Мы находимся в стейте, где, скажем, отрисовываем что-то на экране. Из этого стэйта мы можем перейти в два других по двум разным эвентам. В это время из прерываний нам прилетают 4 эвента, два «наших» с разными приоритетами, и два — для следующих стэйтов. Как тут обойтись (и можно ли) без очереди я пока не знаю. Можно, конечно, возразить что архитектурно не нужно допускать описанных ситуаций, но в том и смысл всяческих диспетчеров и атоматов, чтобы обеспечить гибкость в разработке.