Комментарии 8
Решая такую задач в лоб, используем многопоточность с помощью Thread.
В лоб это когда мы в цикле тупо по очереди посылаем запросы по списку источников, ирония в том что корутины позволяют вот такой тупой последовательный цикл выполнить НЕ последовательно, а (как бы) параллельно.
Но есть альтернатива: в цикле создавать объекты связанные с каждым созданным запросом и складывать их в мап по ИД источника, к которому отослан запрос, и по мере прихода ответов забирать из этого мапа объекты по тому же ИД источника, от которого пришел ответ, и обрабатывать эти ответы соответствующим образом. Вот с алгоритмом с такой стратегией было бы действительно интересно сравнить ваш алгоритм.
Спасибо большое за статью, очень не хватало чего-то такого в момент, когда впервые за них садился.
Было бы здорово, если собственный код был в виде текста, чтобы можно было проще копировать и запускать локально. Или в виде ссылки на репозиторий с исходниками.
Спасибо большое за отличную статью!
runBlocking. При вызове блокируется тред, в котором был запущен этот билдер, а также при каждой приостановке Coroutine. Я не видел, чтобы на нашем проекте это использовалось, но кейсы придумать можно.
С помощью runBlocking можно вызывать suspend функцию из не suspend функции (что в целом логично, вытекает из определений). Это может быть полезно как минимум при написании тестов.
Можешь, пожалуйста, рассказать, для чего вообще скоуп существует?
Я не про его практическое применение в текущей реализации котлин корутин, а про вложенный в него смысл.
Все требующие скоуп методы, например его экстеншены launch() и async(), на самом деле требуют его контекст.
Иерархия корутин строится между джобами посредством хранения ссылок на потомков в родительской джобе.
Управление "сгруппированными" корутинами осуществляется методами, пробрасываемыми к джобе из контекста при ее наличии там и выкидывающими исключение при ее отсутствии.
То есть буквально не нашел какого-то функционала у самого скоупа. Так почему все это не реализовано прямо на контексте?
Давно задавался этим вопросом, но ни дока, ни гугл, ни коллеги не смогли дать ответ.
Код внутри виртуального треда должен быть максимально использующим обычные блокируемые конструкции, так как будто это обычный последовательный код.
Чем это отличается от кода, который я могу написать внутри CompletableFuture в Java? Непонятно, в чём принципиальная разница с CompletableFuture в этом утверждении.
Kotlin Coroutines. Часть 1: Первое погружение