Точно не требуя? У меня на каждое обновление из рустора система вопросы задаёт. Надо, кстати, обновить эти несколько приложений (для этого придётся зайти в second space – по совету из одной из статей на Хабре вынес рустор туда: он обновляет приложения в second space, но они доступны в основном – а то, чего нет в second space, он просто не видит).
Ну вот один (один на поток) бесконечный цикл и много обработчиков прерываний (ну или других обработчиков изменения состояния), внутри которых никаких бесконечных циклов нет.
Пример "плохой" реализации я вам приведу из другой области, уж извините. Программа под MacOS, главный тред, крутится стандартный цикл обработки событий. Нужно показать модальное диалоговое окно. До определённого момента стандартной реализацией этого был блокирующий вызов runModalForWindow:, который внутри себя крутит новый цикл обработки сообщений. И это, к примеру, ломает GCD (Grand Central Dispatch) – ты делаешь вызов dispatch_after (вызов лямбда-функции через заденное время), и... он вызывается после закрытия диалога, потому что в обработчике событий для диалога очередь GCD не разбирается, а главный цикл заблокирован.
Уверен, что в эмбеддинге те же проблемы, только в гораздо большей степени.
Ok, один на тред/генератор/корутину. К проблемам приходишь, когда внутри одного такого цикла дёргаешь другой.
Суть в том, что такой "почти бесконечный" цикл, если не хочешь разгребать проблемы "а почему мы не реагируем на XXX?", должен быть внешним. А внутри желательно достаточно быстро переходить к проверке состояния.
Упс, я облажался, невнимательно прочитал код. Второй – дело криминальное, там почти 100% однажды понадобится обработать что-то, не относящееся ко второй стейт-машине, и прерваться.
Ну так цикл ровно один, как я и сказал несколькими комментами выше. Так что я вас не понял просто потому, что loop() назван обработчик состояния, а не цикл – ну не ардуинщик я, не знаю ваших мемов.
А вот из loop одного устройства звать loop другого – не светлая мысль. Потом оказывается, что приходит какое-то событие для внешней loop, начинаешь городить какие-то обработчики – и понеслось...
Я не снимаю: у меня наушники с хреновым шумодавом, который давит в основном басы – в итоге шуршание шин на фоне приглушённых прочих звуков слышно лучше, чем без наушников.
А вы проверяли на эмуляторе? Получается или старый андроидный смарт расчехлять?
"Отсканируйте qr-код на сайте и подтвердите для перевода денег на безопасный счёт".
У кого дети в школе – скорей всего, понадобится (точнее, не 100% необходимо, но без него будет неудобно).
Точно не требуя? У меня на каждое обновление из рустора система вопросы задаёт. Надо, кстати, обновить эти несколько приложений (для этого придётся зайти в second space – по совету из одной из статей на Хабре вынес рустор туда: он обновляет приложения в second space, но они доступны в основном – а то, чего нет в second space, он просто не видит).
Ну ок, зарегаться через песочницу или сменный телефон и снести нафиг.
Веб-версия изначально живёт в песочнице. А мониторинг на сервере родительского чата – да на здоровье.
Веб-версия. Вечером посмотреть домашку _ хватит.
Так я про то и говорю, что имеет смысл использовать именно так. В OS общего назначения тоже.
Ну вот один (один на поток) бесконечный цикл и много обработчиков прерываний (ну или других обработчиков изменения состояния), внутри которых никаких бесконечных циклов нет.
Пример "плохой" реализации я вам приведу из другой области, уж извините. Программа под MacOS, главный тред, крутится стандартный цикл обработки событий. Нужно показать модальное диалоговое окно. До определённого момента стандартной реализацией этого был блокирующий вызов runModalForWindow:, который внутри себя крутит новый цикл обработки сообщений. И это, к примеру, ломает GCD (Grand Central Dispatch) – ты делаешь вызов dispatch_after (вызов лямбда-функции через заденное время), и... он вызывается после закрытия диалога, потому что в обработчике событий для диалога очередь GCD не разбирается, а главный цикл заблокирован.
Уверен, что в эмбеддинге те же проблемы, только в гораздо большей степени.
Ok, один на тред/генератор/корутину. К проблемам приходишь, когда внутри одного такого цикла дёргаешь другой.
Суть в том, что такой "почти бесконечный" цикл, если не хочешь разгребать проблемы "а почему мы не реагируем на XXX?", должен быть внешним. А внутри желательно достаточно быстро переходить к проверке состояния.
Упс, я облажался, невнимательно прочитал код.
Второй – дело криминальное, там почти 100% однажды понадобится обработать что-то, не относящееся ко второй стейт-машине, и прерваться.
Ну подвесьте на неё что-нибудь более полезное через AutoHotKey.
Я Ctrl-Alt-Del на винде вообще не пользовался (досовские привычки – вздрагивал от этой идеи), Ctrl-Shift-Esc. Ну и Win-L – да (Ctrl-Cmd-Q на маке).
Любимое на винде – win-X.
Ну так цикл ровно один, как я и сказал несколькими комментами выше. Так что я вас не понял просто потому, что loop() назван обработчик состояния, а не цикл – ну не ардуинщик я, не знаю ваших мемов.
loop вызываем или только одну итерацию?
Ну ок, один на тред/генератор/корутину.
А вот из loop одного устройства звать loop другого – не светлая мысль. Потом оказывается, что приходит какое-то событие для внешней loop, начинаешь городить какие-то обработчики – и понеслось...
Я не снимаю: у меня наушники с хреновым шумодавом, который давит в основном басы – в итоге шуршание шин на фоне приглушённых прочих звуков слышно лучше, чем без наушников.
Ну, в норме такой цикл ровно один.
Угу, это тот самый алгоритм, который изобрели удивительно поздно, несмотря на его простоту.