Возможно я что то упустил, но по serve-fixed.go - во первых pending переменная в самом начале не страхует от повторного создания фетча в самом начале - посему проблема остается. Ветка в которой создается новый фетч никак не предотвращает создания повторного фетча по истечении таймера, возможно так нужно НО, - все фетчи работают паралельно и какой из них завершиться раньше в общем случае не предсказуемо - поэтому в данной реализации подписчик может получить новые обновления, а затем более старые обновления. Далее ИМХО - лучше использовать переменные типа каналов прямо в case - не разруливать это выше через логический флаг. Я понимаю что сие не к автору поста, ибо это перевод, но всё же )))
Как уже написали выше - при записи и чтении из nil канала, ошибка возможно при отсутствии других горутин - но это случай обычного дедлока. А вот про саму фишку чтения-записи nil каналов, можно рассказать, как про известный паттерн, разумеется используют в составе select, например при реализации различных state-поведений. В заметке же косвенно вылазит мысль - что не делайте так - это плохо ))).
а особенность его в том, что он работает в отдельном Isolate
— т.е. метод onEventRecived работает в отдельном изоляте так? — ну в принципе полезненько )), но не достаточно что бы (к примеру) уйти от ставшего неким стандартом-де-факто flutter_bloc… — вот если бы ваш пакет наделял эту реализацию такой фичей как обработка ивентов в отдельном изоляте — тогда да, я бы заюзал — ибо есть пара мест в коде, где сейчас используется compute в моих bloc
туристы это деньги, а «халявщики» это нагрузка на инфраструктуру
— да ладно ))) — т.е. я сижу, зарабатываю в Европе деньги, трачу их в Тае и я халявщик??? да я выгодней любого туриста, я по сути занимаюсь перекачкой валюты в страну ))) — разумеется речь про обычных удалёнщиков — зарабатывают в других странах, а тратят в Тае.
И всё равно риск остается, посадят вряд ли, но даже выдворение
— это за то что просто сидишь и в компутере работаешь? хмм не знаю, сколько жил там и в других азиатских странах… Если уж садють и выдворяют — то это за визовые просрочки и всё что с этим связано, но к работе это не имеет отношения
далеко не всегда - its depend...
ничего такого он не держит - соберется gc когда никому станет не нужен
Возможно я что то упустил, но по serve-fixed.go - во первых pending переменная в самом начале не страхует от повторного создания фетча в самом начале - посему проблема остается.
Ветка в которой создается новый фетч никак не предотвращает создания повторного фетча по истечении таймера, возможно так нужно НО, - все фетчи работают паралельно и какой из них завершиться раньше в общем случае не предсказуемо - поэтому в данной реализации подписчик может получить новые обновления, а затем более старые обновления.
Далее ИМХО - лучше использовать переменные типа каналов прямо в case - не разруливать это выше через логический флаг.
Я понимаю что сие не к автору поста, ибо это перевод, но всё же )))
Как уже написали выше - при записи и чтении из nil канала, ошибка возможно при отсутствии других горутин - но это случай обычного дедлока. А вот про саму фишку чтения-записи nil каналов, можно рассказать, как про известный паттерн, разумеется используют в составе select, например при реализации различных state-поведений. В заметке же косвенно вылазит мысль - что не делайте так - это плохо ))).
— это за то что просто сидишь и в компутере работаешь? хмм не знаю, сколько жил там и в других азиатских странах… Если уж садють и выдворяют — то это за визовые просрочки и всё что с этим связано, но к работе это не имеет отношения