Исправление Lilly, (текущая версия) :
Как оно решает когда создавать новые потоки?
Шедулер считает оптимальное число тредов в зависимости от количества работы (если 1 треда хватает, то и ладно), количества ядер (первое время идёт довольно быстро, когда N тредов == N ядер коэффициент докидывания новых тредов сильно снижается по понятным причинам) и потенциальным дедлокам (смотрит на потребление CPU и выполнение, если думает, что тредов мало, чтобы разрулить дедлок, докидывает больше). Есть очереди задач, общая, для таймеров (для нормального латенси по времени) и affinity (для обработки потоковых асинхронных событий от IO, учитывающая, что скорее всего только один тред должен работать с данными от стрима).
Если хочешь поэкспериментировать и у тебя есть rakudo на борту, то просто попробуй позапускать разные примеры с включённой переменной RAKUDO_SCHEDULER_DEBUG, он логгирует, какие потоки и почему создаются. Я сам в core не пишу, но можешь зайти на #moarvm на freenode и спросить, там все нужные люди тебе расскажут, что спросишь.
К примеру, вот тебе сортировка сном(хихи):
my @a = (1..20).pick(*);
await @a.map: -> $n {
start {
say "About to await on $*THREAD.id()";
await Promise.in($n);
say "$n on thread $*THREAD.id()";
}
};
Попробуй угадать, сколько тредов будет работать в этой сортировке, потом запусти и сверь ответ.
Подводные камни - не без них, конечно, изредка бывает, что падает что-нибудь. Ты пишешь, что в go идеально, но у них правда ни одного бага на эту тему в багзилле? Тогда моё уважение. Вот прям сейчас наблюдаю в irc, как разработчики пускают скриптами тысячи потоков, чтобы отлавливать багцы, проводится разный там стресс-тестинг, когда бедный GC заставляют отрабатывать каждые выделенные 512 килобайт, и другие издевательства над кодом.
По тому, что пишут, до уровня вылизанности .net или go пока нет, но вот питон или руби, которые тут называют, пасут задних. Ну и, опять таки, ловля багов это дело времени - есть скилловые core разработчики, есть сообщество.
Исходная версия Lilly, :
Как оно решает когда создавать новые потоки?
Шудулер считает оптимальное число тредов в зависимости от количества работы (если 1 треда хватает, то и ладно), количества ядер (первое время идёт довольно быстро, когда N тредов == N ядер коэффициент докидывания новых тредов сильно снижается по понятным причинам) и потенциальным дедлокам (смотрит на потребление CPU и выполнение, если думает, что тредов мало, чтобы разрулить дедлок, докидывает больше). Есть очереди задач, общая, для таймеров (для нормального латенси по времени) и affinity (для обработки потоковых асинхронных событий от IO, учитывающая, что скорее всего только один тред должен работать с данными от стрима).
Если хочешь поэкспериментировать и у тебя есть rakudo на борту, то просто попробуй позапускать разные примеры с включённой переменной RAKUDO_SCHEDULER_DEBUG, он логгирует, какие потоки и почему создаются. Я сам в core не пишу, но можешь зайти на #moarvm на freenode и спросить, там все нужные люди тебе расскажут, что спросишь.
К примеру, вот тебе сортировка сном(хихи):
my @a = (1..20).pick(*);
await @a.map: -> $n {
start {
say "About to await on $*THREAD.id()";
await Promise.in($n);
say "$n on thread $*THREAD.id()";
}
};
Попробуй угадать, сколько тредов будет работать в этой сортировке, потом запусти и сверь ответ.
Подводные камни - не без них, конечно, изредка бывает, что падает что-нибудь. Ты пишешь, что в go идеально, но у них правда ни одного бага на эту тему в багзилле? Тогда моё уважение. Вот прям сейчас наблюдаю в irc, как разработчики пускают скриптами тысячи потоков, чтобы отлавливать багцы, проводится разный там стресс-тестинг, когда бедный GC заставляют отрабатывать каждые выделенные 512 килобайт, и другие издевательства над кодом.
По тому, что пишут, до уровня вылизанности .net или go пока нет, но вот питон или руби, которые тут называют, пасут задних. Ну и, опять таки, ловля багов это дело времени - есть скилловые core разработчики, есть сообщество.