Я ж сказал, завтра попробую точно, а сейчас просто привёл ту фразу, что читал до этого. Тогда в каком случае полетит исключение, если будет ждать вечно? Странно
Оказывается, first{} - это первое, что я попробовал вчера. Итог был как в описанном мною первом посте - после emit() функция suspend'ится. Почему - неясно. Причём, если постить одну задачу, возвращается один ответ и функция не suspend'ится. А если сразу параллельно накидать несколько задач, то функция приостанавливается на emit(). Накидал пример, с помощью которого можно повторить у себя и получить такой же результат. Если в примере в цикле for указать вместо 100 всего лишь 1 проход, то программа завершится успешно. Если же много проходов, то зависнет. Такие дела. Также прикладываю к посту логи для одного повтора и для 100 чуть ниже.
Правильно я понимаю, что это вы SharedFlow мучаете? Так вот, у его Mutable-версии есть аж три параметра, о которых вам надо знать. С первым все более-менее понятно, а насчёт второго и третьего сейчас мануал один кину.
Да, с sharedflow
https://itnext.io/mutablesharedflow-is-kind-of-complicated-61af68011eae Выше вам по делу подсказали, но мануал гляньте, чтобы понять поведение SharedFlow
Спасибо за ссылку, интересное чтиво. Там примерно описывается моя проблема. Но вот один нюанс не даёт мне покоя. Когда я делаю emit(), то много подписчиков ждут своё сообщение через вызов first{}. First под капотом вызывает collectWhile, который в свою очередь вызывает collect только в том случае, если first вернул true. Когда у нас 100 подписчиков, вытаскивающих один элемент из потока, весь поток стопорится. Что как бы абсурдно, ведь, тогда вся система рано (при extraBufferCapacity=0) или поздно (при большом extraBufferCapacity) приостановится.
Изменение политики onBufferOverflow не решает проблему? Там по-умолчанию саспенд, но можно дропать старые или новые при переполнении буфера.
Нельзя так делать, мне ж нельзя терять запросы на решения задач
Обсуждают сегодня