Почитал доки. Очень классная вещь. Эта штука концептуально похожа на Rx/RxJS

То что на первый взгляд сильно смущает, это то, что futures-signals использует в основе обычные блокирующие RwLock, которые, как я понял из документации, в частности блокируются во время триггера сигналов. И если сам сигнал оказался блокирующим, к примеру, при вызове for_each/map_future, мы фактически заблокируем поток, который в этот момент начнет записывать в источник сигнала. Это автоматически делает источники сигнала неприменимыми(либо неудобно применимыми) в рамках инфраструктуры Tokio или любого другого экзекьютора

я бы на твоём месте сделал форк и заменил локи на tokio:: sync – работы на пару часов, а профит будет. там это сделано так, чтобы не привязываться к рантайму

а если сделаешь это как фичу, то будет повод сделать pr

насколько я знаю RwLock в отличии от Mutex в futures так и не завезли, надо посмотреть

ага, не завезли
https://github.com/rust-lang/futures-rs/pull/2082

Если независимость от рантайма была изначальной целью(что само по себе конечно правильно), вряд ли разработчик примет tokio-зависимые изменения

Может просто оборачивать все обращения к Mutable в tokio::spawn_blocking? Или плохая идея? )

по крайней мере так позиционируется крейт, так что как рабочее решение свой форк, пока в futures не завезли RwLock.

ну, я бы так не стал делать 😉

@diaevd Насколько spawn_blocking вообще дорогой? Это вопрос безотносительно обсуждаемой темы

Я его довольно интенсивно использую для взаимодействия с графической подсистемой, особенно там где CPU блокируется на операциях взаимодействия с GPU(ну, у меня задача такая просто, связанная с интенсивной работой с GPU)

не дороже простого spawn, главное чтобы в экзекуторе были свободные "blocking" потоки, если таких нет, то опаньки, тогда дороже — тогда новый тред стартуется

фактически там все просто, токио смотрит есть ли в пул свободный блокинг, если есть то футуру туда, если нет, то thread::spawn, добавляет его в пул и футуру туда

Почему бы тогда не завернуть операции работы с Mutable в spawn_blocking? У меня, к слову, не весь далеко код неблокирующий. В некоторых случаях мне наоборот нужно работать с данными в обычном треде, независимом от Tokio

билдером можно заранее это зарезервировать, если примерно знаешь сколько у тебя их может быть

так spawn_blocking обычно и юзают для синхронного и как правило блокирующего

поэтому и потоки помечены как blocking

А как он мне поможет?