caxapa.ru :: Суть только в том, есть ли у тебя блокирующие функции (ожидающие чего-либо до возврата, какого-либо события) и функции выполняющие вычисления длительное время. Обычно проще иметь первое и второе, чем разбивать до совсем уж автоматов. Но и первое и

fk0^{легенда} (20.09.2019 10:17, просмотров: 649) ответил SciFi на Враки. Вполне себе веб сервер и всё остальное без всяких ртос. Веб сервер может задержать главный цикл на десяток миллисекунд, в огромном множестве задач это не проблема. Опять же гарантированный отклик можно и нужно делать на прерываниях, а там

Суть только в том, есть ли у тебя блокирующие функции (ожидающие чего-либо до возврата, какого-либо события) и функции выполняющие вычисления длительное время. Обычно проще иметь первое и второе, чем разбивать до совсем уж автоматов. Но и первое и второе ломает и биг луп, и событийное программирование с каким-то event dispatcher'ом. Альтернативой может быть многопоточный event dispatcher, Который обработчики событий запускает на пуле потоков, и если некоторые заблокируются -- не слишком страшно.

[ZX]

Ответить

- Обычно блокирующие вызовы будут. Простой пример: если записать файл можно и в фоне (свободное от всего остального время), то необходимость чтения блокирует задачу (опять же, если задача не проверяет "is-readable?". - Dingo(21.09.2019 18:57)
- Как правило, блокирующую функцию или длительное вычисление можно разбить на части, и проблема уходит. Да, некий дополнительный геморрой, зависит от конкретной ситуации. Если же код чужой, лезть туда не комильфо, проще RTOS накатить. - SciFi(20.09.2019 10:25)
  - Да всё можно, только код выворвачивать наизнанку, в языке для этого не предназначенном (C), где переменные в стеке и контекст на "переключениях задач" теряется -- очень тяжело. - fk0(20.09.2019 11:15)

Микроконтроллеры