В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Kotlin Community

3845 membersпожаловаться на группу
2020 November 09

AN

Alexander Nozik in Kotlin Community
Kirill Gamazkov
Сильно больше цп не надо по идее. Там же фишка в work stealing, так? Т. е. даже если будет много IO, то достаточно нескольких тредов в отдельном диспетчере, чтобы дожидались завершения IO, а для вычислительной части 2 х кол-во ядер потоков в пуле достаточно должно быть
Work stealing не имеет к корутинам отношения, это делается пулом, который работает под диспатчером
источник
11:59пожаловаться#1

KG

Kirill Gamazkov in Kotlin Community
саша сок #KotlinGang
проблема блокирующих операций в том, что корутина дальше не пойдет, пока операция не выполнится. поэтому либо делить операцию на сиквенсы делать суспенд функции, чем занимаются библиотеки (в случае с интернет-запросами), либо выполнять в IO, который корутины не в одном потоке выполняет
... либо уходить в NIO1 или NIO2. Первый, на коллбэках, по-моему сам под капотом использует небольшой тредпул, а второй, на селекторах, даёт тебе контроль (и геморрой) над частотой опроса событий
источник
11:59пожаловаться#2

АО

Алексей Овсянников... in Kotlin Community
Алексей Овсянников
нет, так уж исторически сложилось,Ю что чтобы дождаться ответа из сокета/от системы/etc., нужно залочить поток до получения собственно ответа
механизм IO в корутинах заточен на создание достаточно большого пула тредов просто затем, чтобы их блокировать на таких операциях
источник
11:59пожаловаться#3

AE

Alexandr Emelyanov in Kotlin Community
Kirill Gamazkov
Сильно больше цп не надо по идее. Там же фишка в work stealing, так? Т. е. даже если будет много IO, то достаточно нескольких тредов в отдельном диспетчере, чтобы дожидались завершения IO, а для вычислительной части 2 х кол-во ядер потоков в пуле достаточно должно быть
просто в случае большого количества именно тредов - их переключать будет ОС, а в случае количества потоков, равному конкаренси цпу - другие корутины не запустятся, пока не добегут запущенные
источник
12:00пожаловаться#4

АО

Алексей Овсянников... in Kotlin Community
думаю, как и сказал @noraltavir , в обычных тредах (экзекутерах Java) это работает по тому же принципу
источник
12:00пожаловаться#5

AE

Alexandr Emelyanov in Kotlin Community
и речь при этом именно про вычисления без IO
источник
12:00пожаловаться#6

KG

Kirill Gamazkov in Kotlin Community
Alexandr Emelyanov
просто в случае большого количества именно тредов - их переключать будет ОС, а в случае количества потоков, равному конкаренси цпу - другие корутины не запустятся, пока не добегут запущенные
> другие корутины не запустятся, пока не добегут запущенные
А, ну если запущенные не делают время от времени yield, то да, вы правы
источник
12:00пожаловаться#7

АО

Алексей Овсянников... in Kotlin Community
Alexandr Emelyanov
просто в случае большого количества именно тредов - их переключать будет ОС, а в случае количества потоков, равному конкаренси цпу - другие корутины не запустятся, пока не добегут запущенные
Не совсем так. Диспетчеры существуют, чтобы разделить потоки между собой. Если вы работаете в Default диспетчере - вам будет глубоко всё равно, сколько там на IO заблокировано потоков
источник
12:01пожаловаться#8

АО

Алексей Овсянников... in Kotlin Community
хотя я вот задумался и понял, что могу тут ошибаться
источник
12:01пожаловаться#9

AE

Alexandr Emelyanov in Kotlin Community
Алексей Овсянников
Не совсем так. Диспетчеры существуют, чтобы разделить потоки между собой. Если вы работаете в Default диспетчере - вам будет глубоко всё равно, сколько там на IO заблокировано потоков
все сообщения читаются, нет?
https://t.me/kotlin_lang/214453
Telegram
Alexandr Emelyanov in Kotlin Community
и речь при этом именно про вычисления без IO
источник
12:01пожаловаться#10

KG

Kirill Gamazkov in Kotlin Community
Алексей Овсянников
механизм IO в корутинах заточен на создание достаточно большого пула тредов просто затем, чтобы их блокировать на таких операциях
Ну, повторюсь, достаточно часто это можно через NIO разрулить
источник
12:02пожаловаться#11

АО

Алексей Овсянников... in Kotlin Community
Alexandr Emelyanov
все сообщения читаются, нет?
https://t.me/kotlin_lang/214453
Telegram
Alexandr Emelyanov in Kotlin Community
и речь при этом именно про вычисления без IO
упустил:)
источник
12:02пожаловаться#12

AE

Alexandr Emelyanov in Kotlin Community
Kirill Gamazkov
> другие корутины не запустятся, пока не добегут запущенные
А, ну если запущенные не делают время от времени yield, то да, вы правы
а зачем? зачем в логику вычислений внедрять логику переключения между вычислениями, если это сделано уже на уровне ОС?
источник
12:02пожаловаться#13

AE

Alexandr Emelyanov in Kotlin Community
Алексей Овсянников
упустил:)
👍
источник
12:03пожаловаться#14

АО

Алексей Овсянников... in Kotlin Community
Alexandr Emelyanov
все сообщения читаются, нет?
https://t.me/kotlin_lang/214453
Telegram
Alexandr Emelyanov in Kotlin Community
и речь при этом именно про вычисления без IO
но в этом плане там уже начинается магия, потому что система может очень захотеть тормознуть любой поток в любой момент, так что я тут вообще не могу ручаться, как оно отработает:)
источник
12:03пожаловаться#15

KG

Kirill Gamazkov in Kotlin Community
Alexandr Emelyanov
а зачем? зачем в логику вычислений внедрять логику переключения между вычислениями, если это сделано уже на уровне ОС?
Затем, что в многопоточности очень мало что разруливается полностью автоматикой. Ручная работа всегда остаётся.
В JVM же, в отличие от ОС, другая модель многопоточности - кооперативная, а не вытесняющая. И пока сам поток не согласиться прерваться, никто этого сделать не сможет извне. Только попросить.
источник
12:04пожаловаться#16

AE

Alexandr Emelyanov in Kotlin Community
Алексей Овсянников
но в этом плане там уже начинается магия, потому что система может очень захотеть тормознуть любой поток в любой момент, так что я тут вообще не могу ручаться, как оно отработает:)
ну не магия, системные шедулеры документированы и их алгоритм определен
источник
12:04пожаловаться#17

АО

Алексей Овсянников... in Kotlin Community
Alexandr Emelyanov
ну не магия, системные шедулеры документированы и их алгоритм определен
ну я скорее к тому, что там сложно будет сказать, кто когда встанет
источник
12:05пожаловаться#18

AE

Alexandr Emelyanov in Kotlin Community
Алексей Овсянников
ну я скорее к тому, что там сложно будет сказать, кто когда встанет
ну тут да, но это все равно лучше ручного управления
источник
12:05пожаловаться#19

KG

Kirill Gamazkov in Kotlin Community
Alexandr Emelyanov
ну не магия, системные шедулеры документированы и их алгоритм определен
Алгоритм-то определён, а входные события происходят считай случайно
источник
12:05пожаловаться#20