V
вот именно, как!? 😄
Так а зачем все таки флоу, если можно просто из корутины все пихнуть в канал?) Ну и если так хочется - channel.asFlow )
Size: a a a
2020 February 03
K
сейчас наверное уже да, но по началу как канал не выглядело)) Просто, если бы возвращал по-порядку то делал бы await в цикле и хватило бы флоу, а если по мере поступления, то канал? Как-то странно, не?
SB
Не оч понимаю, а вариант с List<Deferred> возвращенный от async с последующим List<Deferred>.awaitAll() это неправильный подход?
K
awaitAll же все скопом
SB
А, надо по мере поступления, да, в глаза долблюсь. А вообще это нормально, или это тоже надо на флоу/каналах делать? Если просто куча параллельных запросов хочется
AO
А почему это вообще всё не обработать как отдельные запросы?
AO
Если порядок не важен и не нужно чтобы все вместе
SB
Если порядок не важен и не нужно чтобы все вместе
Если мне, то важна параллельность, что не друг за дружкой
AO
Не оч понимаю, а вариант с List<Deferred> возвращенный от async с последующим List<Deferred>.awaitAll() это неправильный подход?
Тогда это ок
VP
Народ, а какие вообще гарантии на suspend'ах и try finally?
Есть ли кейсы, когда bar не вызовется?
try {
foo() //suspension
} finally {
bar()
}Есть ли кейсы, когда bar не вызовется?
Должен вызываться всегда, если никто не начудит с низкоуровневыми примитивами и не потеряет Continuation.
Ещё есть такой ньюанс, что в bar() корутина может быть уже отменена и может понадобиться withContext(NonCancellable)
Ещё есть такой ньюанс, что в bar() корутина может быть уже отменена и может понадобиться withContext(NonCancellable)
AO
Должен вызываться всегда, если никто не начудит с низкоуровневыми примитивами и не потеряет Continuation.
Ещё есть такой ньюанс, что в bar() корутина может быть уже отменена и может понадобиться withContext(NonCancellable)
Ещё есть такой ньюанс, что в bar() корутина может быть уже отменена и может понадобиться withContext(NonCancellable)
хммммм, а вот этот второй моментик, есть где почитать?
VP
хммммм, а вот этот второй моментик, есть где почитать?
AO
А это про bar, что то я тупанул
AN
Ну, вопрос философский) Когда начинал, со стороны очень казалось, что вытягиваю. Например, обычный GET для одной картинки - вытягивание? А тут вытягивание списка картинок. Инициатор - пользователь, со стороны все выглядит холодным, это ж не сенсор какой-то.
Так ChannelFlow же. Со сотроны, где пихаете - канал, с другой стороны Flow.
AN
Насколько я понимаю, те же самые, которые на обычный try. Там только проблема в том, что корутины без обвязки сами исключения не прокидывают за скоуп. Надо библиотекчными пользоваться
AN
Не оч понимаю, а вариант с List<Deferred> возвращенный от async с последующим List<Deferred>.awaitAll() это неправильный подход?
Это про параллельное выполнение, а не про выпихнуть по мере завершения
AO
Насколько я понимаю, те же самые, которые на обычный try. Там только проблема в том, что корутины без обвязки сами исключения не прокидывают за скоуп. Надо библиотекчными пользоваться
Ну меня волнуют только гарантии исполнения finally
AN
Ну меня волнуют только гарантии исполнения finally
Вот это, я думаю, гарантированно.
BP
да вернуть флоу, например, который будет отдавать их по мере поступления.(или, если без флоу, то хоть массив результатов, отсортированый по очередности результатов, но без хаков типа таймстемпа или айдишников).
Все зависит от применения. Если тип одинаковый то асинки заганяем в лист и ждём
AF
Всем привет.
Я использую callbackFlow и опертор buffer(Channel.Factory.UNLIMITED)
Как можно пологгировать заполненость канала?
Хочу убедиться, что данные в нем не вызовут OOM.
Я использую callbackFlow и опертор buffer(Channel.Factory.UNLIMITED)
Как можно пологгировать заполненость канала?
Хочу убедиться, что данные в нем не вызовут OOM.