Телеграмм чат группы rust

Даже если ты пошлешь его на отдельный тредпул, он продолжит отбирать ресурсы CPU у обычных футур

23:17пожаловаться #1

AE

Alexey Ermakov in Rust Async

вафель 🧇

А как понять что блокирующего кода достаточно, чтобы засунуть его в spawn_bloking?

У меня в async fn достаточно много (?) вычислений, итерирации по массивам, оперирования хэшмапами, etc — приличный кусок 100% блокирующего кода. Думаю вот добавлять spawn_blocking или нет.

в доке, вроде, было мельком что-то сказано про блокирующее io

23:19пожаловаться #2

в🧇

Даже если ты пошлешь его на отдельный тредпул, он продолжит отбирать ресурсы CPU у обычных футур

CPU да, но у меня не настолько много расчётов чтобы это влияло. Просто в цикле ~пару раз в секунду проверяю некоторые время-зависимые данные.

Тут скорее интереснее что scheduler может иметь мало потоков для асинхронных операций (1-2?) и тогда это возможно станет проблемой.

23:20пожаловаться #3

MB

Ну если он сейчас не тратит время попусту (например в нем ничего типа std::thread::sleep, синхронного IO и так далее), то непонятно как он может выиграть от spawn_blocking.
Количество потоков для исполнения футур задается настройкой core_threads и по-умолчанию равно кол-ву ядер ЕМНИП.

23:22пожаловаться #4

в🧇

Ну если он сейчас не тратит время попусту (например в нем ничего типа std::thread::sleep, синхронного IO и так далее), то непонятно как он может выиграть от spawn_blocking.
Количество потоков для исполнения футур задается настройкой core_threads и по-умолчанию равно кол-ву ядер ЕМНИП.

Он, не может, в теории могут выиграть другие футуры.

23:23пожаловаться #5

в🧇

Но идею понял, спасибо

23:24пожаловаться #6

MB

Ну если ты аккуратно настроишь все, то какие-то отдельные показатели можно улучшить.
Например каким-то образом понизить приоритет потоков для этих блокирующих тасок. Тогда нормальные футуры действительно начнут работать быстрее (ну то есть больше поллов в секунду) ценой лишнего замедления этого CPU-heavy кода.

23:25пожаловаться #7

в🧇

Ну если он сейчас не тратит время попусту (например в нем ничего типа std::thread::sleep, синхронного IO и так далее), то непонятно как он может выиграть от spawn_blocking.
Количество потоков для исполнения футур задается настройкой core_threads и по-умолчанию равно кол-ву ядер ЕМНИП.

На счёт core_threads: по умолчанию то да, но это можно и изменить :) Я библиотеку пишу, так что хочу от всего предостеречься...

23:29пожаловаться #8

MB

Ну в общем случае разные юзеры могут захотеть по-разному тюнить приоритеты.
Поэтому тогда, если есть такая возможность, ты можешь на вход брать трейт, который умеет спаунить футуры разных видов.

23:32пожаловаться #9

MB

Или даже возвращать футуры и просить юзера самостоятельно заспавнить

23:32пожаловаться #10

в🧇

Кстати я может что-то путаю, но разве макрос не устанавливает по умолчанию один тред?

https://github.com/tokio-rs/tokio/blob/971ed2c6df9cb3bf3543a9c780662a0b4d1a8d40/tokio-macros/src/entry.rs#L131

В макросах так сложно разбираться...

A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ... - tokio-rs/tokio

23:34пожаловаться #11

в🧇

Или даже возвращать футуры и просить юзера самостоятельно заспавнить

Я уже...

Но тут вопрос всё же про блокирующий код внутри

23:35пожаловаться #12

MB

spawn_blocking небесплатный. Каждая блокирующая таска сидит на своем потоке, то есть spawn_blocking может привести к запуску системного треда

23:36пожаловаться #13

MB

вафель 🧇

Кстати я может что-то путаю, но разве макрос не устанавливает по умолчанию один тред?

https://github.com/tokio-rs/tokio/blob/971ed2c6df9cb3bf3543a9c780662a0b4d1a8d40/tokio-macros/src/entry.rs#L131

В макросах так сложно разбираться...

A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ... - tokio-rs/tokio

Если включен rt-threaded, то включается многопоточный экзекутор.
А для него core_threads вычисляется так: https://github.com/tokio-rs/tokio/blob/971ed2c6df9cb3bf3543a9c780662a0b4d1a8d40/tokio/src/runtime/builder.rs#L538

A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ... - tokio-rs/tokio

23:38пожаловаться #14

в🧇

Если включен rt-threaded, то включается многопоточный экзекутор.
А для него core_threads вычисляется так: https://github.com/tokio-rs/tokio/blob/971ed2c6df9cb3bf3543a9c780662a0b4d1a8d40/tokio/src/runtime/builder.rs#L538

A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ... - tokio-rs/tokio

min(512, num_cpus())

Ого ммм

23:39пожаловаться #15

2020 October 01

KR

Kai Ren in Rust Async

гипер квад тред риппер?

00:23пожаловаться #16

в🧇

Kai Ren

гипер квад тред риппер?

Там max_threads с расчётом на блокирующее IO

00:30пожаловаться #17

AI

Alex Ilizarov in Rust Async

Hirrolot

ну насколько помню, httparse довольно криво спроектирован

а че там не так?

08:53пожаловаться #18

DF

Dollar Føølish in Rust Async

я не знаю что там не так но мне тоже интересно узнать

09:08пожаловаться #19

M

Max in Rust Async

Если включен rt-threaded, то включается многопоточный экзекутор.
А для него core_threads вычисляется так: https://github.com/tokio-rs/tokio/blob/971ed2c6df9cb3bf3543a9c780662a0b4d1a8d40/tokio/src/runtime/builder.rs#L538

A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ... - tokio-rs/tokio

А разве блокирующий тред пул не отдельно от основного работает?