Комментарии 30
Поиск по GitHub по запросу
while(true)даёт тысячи совпадений
А почему он не должен давать тысячи совпадений, если это типовая реализация метода run у интерфейса Runnable ???
Как по мне, исправление напоминает костыль. 256 итераций. Почему не 8? Или не 32768?
Вам не кажется, что перевод статей 2015 года - это кризис жанра и надо как-то пересмотреть стратегию развития своего паблика?
Не, я понимаю - есть "не стареющая классика", но, мяу?!
Никогда не используйте потенциально бесконечные циклы
хрень полная.
Любое встроенное ПО использует бесконечные циклы. Или в виде машины состояний или в ардуино стиле с setup() и loop(). И не обязательно встроенное.
Так это наверное как раз non-terminating
Ну, в норме такой цикл ровно один.
из одной машины состояний состояний легко и непринужденно вызывается другая машина состояний, аналогично из loop() вызывается другой loop какого-нибудь устройства. Для серверов оно обычно обзывается обработчиком клиента и обычно живет в отдельной нитке/потоке/процессе или прости господи корутине
Ну ок, один на тред/генератор/корутину.
А вот из loop одного устройства звать loop другого – не светлая мысль. Потом оказывается, что приходит какое-то событие для внешней loop, начинаешь городить какие-то обработчики – и понеслось...
так нету в машине состояний прихода событий, есть бег по кругу/прыг по состояниям и опрос ног/регистров состояний/флагов
А вот из loop одного устройства звать loop другого – не светлая мысль.
loop устройств вызываем из общего loop'а
loop вызываем или только одну итерацию?
main()
{
setup();
while(1)
loop();
}
void loop(void)
{
loop_dev1();
loop_dev2();
}
void loop_dev1(void)
{
switch(state1)
{
case 0:
state1++;
break;
case 1:
state1++;
break;
.....
case N:
state1 = 0;
break;
}
}
void loop_dev2(void)
{
while(1)
{
switch(state2)
{
case 0:
state2++;
break;
case 1:
state2++;
break;
.....
case N:
state2 = 0;
return;
}
}
}возможны варианты. Предпочтителен первый, но если очень надо, то второй
Ну так цикл ровно один, как я и сказал несколькими комментами выше. Так что я вас не понял просто потому, что loop() назван обработчик состояния, а не цикл – ну не ардуинщик я, не знаю ваших мемов.
Упс, я облажался, невнимательно прочитал код.
Второй – дело криминальное, там почти 100% однажды понадобится обработать что-то, не относящееся ко второй стейт-машине, и прерваться.
в ардуино стиле нет main(), есть setup() и loop(). Точнее, main() спрятана от кривых ручек, а loop() вызывается из этого спрятанного main() из бесконечного цикла, ну а все вложенные бесконечные циклы - по вкусу и цвету
Почему? Под управлением RTOS вполне можно иметь множество задач с такими циклами. Это даже не считая того, что PIO в RP2040 почти всегда работает именно по такому циклу. Так же, как нередко, DMA в кольцевой буфер, например, с ADC.
Ok, один на тред/генератор/корутину. К проблемам приходишь, когда внутри одного такого цикла дёргаешь другой.
Суть в том, что такой "почти бесконечный" цикл, если не хочешь разгребать проблемы "а почему мы не реагируем на XXX?", должен быть внешним. А внутри желательно достаточно быстро переходить к проверке состояния.
С первым абзацем понятно. Подобные обработчики по необходимости или формируют прерывание, или забрасывают сообщения в кольцевой буфер и ничего вызывать не должны.
А второй абзац вообще не понял. На обработку изменения состояния переходим или по прерыванию, размещающему сообщение в кольцевом буфере, или по сообщению в этом же кольцевом буфере, если его туда поместил цикл опроса. И везде бесконечные циклы, выход из которых вообще не имеет смысл.
Ну вот один (один на поток) бесконечный цикл и много обработчиков прерываний (ну или других обработчиков изменения состояния), внутри которых никаких бесконечных циклов нет.
Пример "плохой" реализации я вам приведу из другой области, уж извините. Программа под MacOS, главный тред, крутится стандартный цикл обработки событий. Нужно показать модальное диалоговое окно. До определённого момента стандартной реализацией этого был блокирующий вызов runModalForWindow:, который внутри себя крутит новый цикл обработки сообщений. И это, к примеру, ломает GCD (Grand Central Dispatch) – ты делаешь вызов dispatch_after (вызов лямбда-функции через заденное время), и... он вызывается после закрытия диалога, потому что в обработчике событий для диалога очередь GCD не разбирается, а главный цикл заблокирован.
Уверен, что в эмбеддинге те же проблемы, только в гораздо большей степени.
Хороший программист — это тот, кто смотрит по обеим сторонам, переходя улицу с односторонним движением.
Хороший программист — это тот, кто при переходе улицы снимает наушники, то есть пользуется всенаправленным звуковым датчиком, который определяет приближение угрозы с любого направления (а бесшумных автомобилей пока что не изобрели).
Глаза у человека находяться перед ушами, так что есть шанс увидеть автомобиль раньше чем услышать.
Автомобиль, который можно раньше увидеть, чем услышать, оштрафуют за превышение скорости (звука).
Анекдот (физический)"
Летят две вороны с дозвуковой скоростью.
— Забор!!!
— Вижу!
Шмяк!
Шмяк!
Летят две вороны со сверхзвуковой скоростью.
— Забор!!!
Шмяк!
— Вижу!
Шмяк!
Летят две вороны с гиперзвуковой скоростью.
Шмяк!
Шмяк!
— Вижу!
— Забор!!!
Звук обрабатывается быстрее чем визуальная информация.
Есть условно бесшумные - электрички те же, да на свежем снежке.. а так, у программиста в этот звуковой датчик давно встроен нейронный шумодав, для игнорирования внешних раздражителей, куда и профили автозвука давно внесены.
Я не снимаю: у меня наушники с хреновым шумодавом, который давит в основном басы – в итоге шуршание шин на фоне приглушённых прочих звуков слышно лучше, чем без наушников.
Бесконечные циклы. Всё, что может пойти не так — пойдёт не так