Size: a a a

Kotlin Community

2019 November 20

AN

Alexander Nozik in Kotlin Community
Классический work-strealing pool пока на нейтиве не особо фурыкает
источник

СГ

Сергей Греков in Kotlin Community
Oleg Yukhnevich
когда есть пул потоков, значит твой код может начать выполняться на одном потоке, а продолжить на другом, и в этом случае происходит шаринг
(если я всё правильно понял, не спец по нативу)
Ну кстати да, точно
источник

OY

Oleg Yukhnevich in Kotlin Community
https://github.com/Kotlin/kotlinx.coroutines/blob/native-mt/kotlin-native-sharing.md
"An active coroutine has a mutable state. It cannot migrate from thread to thread. A coroutine in Kotlin/Native is always bound to a specific thread. Coroutines that are detached from a thread are currently not supported."
источник

OY

Oleg Yukhnevich in Kotlin Community
и там пошло в общем много ещё инфы, я думаю это поможет понять
источник

СГ

Сергей Греков in Kotlin Community
Vladimir Petrakovich
Ну так что вам мешает дёргать ktor или sqldelight без Dispatchers.IO? Блокирующий код если там и есть, то глубоко внутри, вам наружу выставляется нормальный интерфейс.
У меня в либе абстракция над сайд эффектами, там нет прямых вызовов ktor или чего то похожего.
Есть необходимость выполнять корутины иногда на в Main диспатчере, иногда в блокирующем.
https://github.com/FactoryMarketRetailGmbH/RxElm/blob/master/rxelm/src/main/java/com/factorymarket/rxelm/effect/coroutine/CoroutinesCommandExecutor.kt
источник

VP

Vladimir Petrakovich in Kotlin Community
Сергей Греков
У меня в либе абстракция над сайд эффектами, там нет прямых вызовов ktor или чего то похожего.
Есть необходимость выполнять корутины иногда на в Main диспатчере, иногда в блокирующем.
https://github.com/FactoryMarketRetailGmbH/RxElm/blob/master/rxelm/src/main/java/com/factorymarket/rxelm/effect/coroutine/CoroutinesCommandExecutor.kt
И что, там нельзя использовать Dispatchers.Default?
источник

СГ

Сергей Греков in Kotlin Community
Vladimir Petrakovich
И что, там нельзя использовать Dispatchers.Default?
Default как раз можно, вопрос был про IO.
источник

VP

Vladimir Petrakovich in Kotlin Community
Сергей Греков
Default как раз можно, вопрос был про IO.
Я имею в виду, вам там точно нужен IO, а не Default?
источник

VP

Vladimir Petrakovich in Kotlin Community
Разделение кода, который работает на Main и Default - это понятно. Но IO нужен только для прямого вызова кода, который блокирует поток. В common это не нужно.
источник

СГ

Сергей Греков in Kotlin Community
Oleg Yukhnevich
и там пошло в общем много ещё инфы, я думаю это поможет понять
Т.е. сейчас получается на K/N для фоновых запросов нужно юзать Default, который по умолчанию привязан к одному потоку, и все входящие данные в эту корутину будут фризиться, так? В будущем потенциально Default можно быть расширен на много потоков, но они все равно будут жестко привязаны к своим экземплярам потоков, правильно я понял?
источник

СГ

Сергей Греков in Kotlin Community
Vladimir Petrakovich
Я имею в виду, вам там точно нужен IO, а не Default?
Ну похоже что у меня нет выбора
источник

RE

Roman Elizarov in Kotlin Community
val myIO = newSingleThreadContext(“myIO”)
источник

СГ

Сергей Греков in Kotlin Community
Roman Elizarov
val myIO = newSingleThreadContext(“myIO”)
Спасибо, Роман)
источник

OY

Oleg Yukhnevich in Kotlin Community
Сергей Греков
Т.е. сейчас получается на K/N для фоновых запросов нужно юзать Default, который по умолчанию привязан к одному потоку, и все входящие данные в эту корутину будут фризиться, так? В будущем потенциально Default можно быть расширен на много потоков, но они все равно будут жестко привязаны к своим экземплярам потоков, правильно я понял?
Default наверно не надо использовать для блокирующих задач
лучше использовать созданный контекст
и в теории, если одного потока мало будет, можно какой-то свой "пул" сделать, который будет смотреть, сколько есть свободных воркеров и пушить в них задачу
в общем, где-то я такое уже видел, вроде как раз в докладе Романа
источник

СГ

Сергей Греков in Kotlin Community
Vladimir Petrakovich
Разделение кода, который работает на Main и Default - это понятно. Но IO нужен только для прямого вызова кода, который блокирует поток. В common это не нужно.
Возможно я не до конца понял как работают корутиновые диспатчеры. Если я не хочу чтобы код блокировал текущий тред, но и чтобы на каждый таск корутина не создавала новый тред, какой диспатчер надо использовать?
источник

СГ

Сергей Греков in Kotlin Community
Oleg Yukhnevich
Default наверно не надо использовать для блокирующих задач
лучше использовать созданный контекст
и в теории, если одного потока мало будет, можно какой-то свой "пул" сделать, который будет смотреть, сколько есть свободных воркеров и пушить в них задачу
в общем, где-то я такое уже видел, вроде как раз в докладе Романа
Воспользуюсь советом Романа выше)
источник

VP

Vladimir Petrakovich in Kotlin Community
Сергей Греков
Возможно я не до конца понял как работают корутиновые диспатчеры. Если я не хочу чтобы код блокировал текущий тред, но и чтобы на каждый таск корутина не создавала новый тред, какой диспатчер надо использовать?
С блокировкой треда надо разбираться в коде под конкретную платформу, вставляя где надо withContext(IO) { ... }. Только там идёт взаимодействие с кодом, который может заблокировать поток и ждать ответ откуда-то неизвестно сколько времени.
Либо если у вас какая-то тяжёлая вычислительная задача, её тоже имеет смысл выполнять на IO или в отдельном пуле из одного или нескольких потоков.
А так практически всё можно запускать на Default.
источник

VP

Vladimir Petrakovich in Kotlin Community
Ну и любой нормальный диспатчер не создаёт новый тред на каждую корутину :)
источник

СГ

Сергей Греков in Kotlin Community
Roman Elizarov
val myIO = newSingleThreadContext(“myIO”)
Роман, newSingleThreadContext помечен как ObsoleteCoroutinesApi. Какая замена ему планируется? Из комментария не до конца ясно(
источник

RE

Roman Elizarov in Kotlin Community
Будет что-то типа Dispatchers.Default.newLimitedContext(1)
источник