N
На прикладном уровне не надо особо вдаваться в реализацию же
Size: a a a
2018 November 21
N
Не?
RI
Можно ли считать что корутины не имеют отношения к потокам, а просто выполняются вперемешку внутри одного потока, когда есть возможность?
Можно считать что на одном потоке можно запустить любое количество корутин
RI
При этом обычно имеет смысл запустить множество корутин, но могут быть и случаи когда корутина == поток
Ⓢ
Всем привет! Мы составляем карту технологий Kotlin. Пожалуйста, дополните и скорректируйте кто как считает нужным: https://app.mindmup.com/map/_free/2018/11/34f654d0ecd811e8919449fb6e2f898b
Ⓢ
Особенно требуется проработка области mobile, android.
Ⓢ
Ⓢ
Разыскивается докладчик по технологиям: Exposed, Coroutines. Имеющие реальный опыт использования - пишите в личку!
AN
Всем привет! Мы составляем карту технологий Kotlin. Пожалуйста, дополните и скорректируйте кто как считает нужным: https://app.mindmup.com/map/_free/2018/11/34f654d0ecd811e8919449fb6e2f898b
Нету градл и мультиплатформы.
AN
Я вроде как добавил. Но не понял, сохранилось оно или нет
Ⓢ
Мультиплатформа - это jvm или нет?
AN
Нет, это мультиплатформные сборки
Ⓢ
При сохранении создаётся новая ссылка и новый документ
AN
При сохранении создаётся новая ссылка и новый документ
Ну вот тогда копия: https://app.mindmup.com/map/_free/2018/11/47fc8980edbb11e89303ff0d8357aa47
AN
Там внизу про сборку
DP
MZ
Раз уж пошёл вопрос про корутины... А есть у кого-то опыт их использования вместо Future и подобных механизмов для обсчёта связанных задач? Объясню проблему - есть куча неких тасков, которые зависят друг от друга как орграф (без циклов). Надо как-то это обсчитать. Задачи считаются за миллисекунды и их общее количество - несколько тысяч. Они хорошо параллелятся, так что они считаются максимальным эффективным кол-вом потоков для текущего окружения. Сейчас у нас всё это пашет через кастомный раннер, который ну очень похож на то, что сделано в котлин для корутин, но конечно менее эффективный (в плане переключения контекстов). Я подумываю о переходе на корутины, но здесь меня напрягает то, что мониторинг всё равно придётся какой-то свой делать. То есть, дедлок корутин, если я правильно понимаю, не детектится котлином, так что можно встрять, если не делать какие-то свои костылики сбоку. Вроде race-detectors для корутин котлина обсуждались на форумах, но все похоже пилят какие-то свои велосипеды
AN
Есть. Как-нибудь не с мобилки напишу. Если циклов нет, то дедлоку взяться неоткуда
2018 November 22
OP
Maxim Zinchenko
Раз уж пошёл вопрос про корутины... А есть у кого-то опыт их использования вместо Future и подобных механизмов для обсчёта связанных задач? Объясню проблему - есть куча неких тасков, которые зависят друг от друга как орграф (без циклов). Надо как-то это обсчитать. Задачи считаются за миллисекунды и их общее количество - несколько тысяч. Они хорошо параллелятся, так что они считаются максимальным эффективным кол-вом потоков для текущего окружения. Сейчас у нас всё это пашет через кастомный раннер, который ну очень похож на то, что сделано в котлин для корутин, но конечно менее эффективный (в плане переключения контекстов). Я подумываю о переходе на корутины, но здесь меня напрягает то, что мониторинг всё равно придётся какой-то свой делать. То есть, дедлок корутин, если я правильно понимаю, не детектится котлином, так что можно встрять, если не делать какие-то свои костылики сбоку. Вроде race-detectors для корутин котлина обсуждались на форумах, но все похоже пилят какие-то свои велосипеды
В корутинах, как и в ForkJoinPool, дедлок невозможен. join() не блокирующий. Для вашего случая корутины идеально подходят