IL
Да, у меня не иерархическая, вернее, зависимость )
Size: a a a
2020 July 12
IL
*между тасками
d
Да, у меня не иерархическая, вернее, зависимость )
ну да, я неверно выразился, в общем у тебя нет тупого от парента к чайлдам
IL
Если честно, у меня даже "пользовательский интерфейс" не очень обычный. У меня есть куча скриптов, которые выполняются по разным событиям(по событиям изменения файла скрипта, по таймерам, по некоторым другим событиям), и несколько тасок, которые рендерят некоторые вещи на GPU, причем не всегда в GUI окна
IL
Соответственно, есть таски, которые следят за изменением файлов, компилируют скрипты, рендерят на GPU, генерируют тики таймеров и многое другое. И многие из них имеют довольно тяжеловесное состояние, которое нельзя пересоздавать каждый раз, его нужно кешировать.
IL
И все это нужно как-то останавливать так, чтобы остаточные рабочие процессы между тасками к моменту начала остановки имели возможность завершиться
IL
@diaevd Нормально ли, что в функции поллинга фьючеров сигналов futures-signals каждый раз делают read-lock блокирующего RwLock?
KR
То что на первый взгляд сильно смущает, это то, что futures-signals использует в основе обычные блокирующие RwLock, которые, как я понял из документации, в частности блокируются во время триггера сигналов. И если сам сигнал оказался блокирующим, к примеру, при вызове for_each/map_future, мы фактически заблокируем поток, который в этот момент начнет записывать в источник сигнала. Это автоматически делает источники сигнала неприменимыми(либо неудобно применимыми) в рамках инфраструктуры Tokio или любого другого экзекьютора
Я смотрел код когда-то. Не будет там блокирования потока. Автор не дурак.
Сам юзал в многопотоке - всё чики-поки?
Сам юзал в многопотоке - всё чики-поки?
KR
@diaevd Нормально ли, что в функции поллинга фьючеров сигналов futures-signals каждый раз делают read-lock блокирующего RwLock?
Да. В функции поллинга это полностью разрешено. Вызов функции поллинга не живёт across .await points.
С этими блокирующими RwLock/Mutex карго-культ какой-то. Кто-то сказал, что они могут блокануть весь реактор, если их удерживать across .await points, кто-то услышал только "блокануть весь реактор", и теперь они прям как под каким-то табу. Кто-то виде в асинхронщине обычный Mutex, и сразу крик "О нет, оно заблкоирует всё!".
С этими блокирующими RwLock/Mutex карго-культ какой-то. Кто-то сказал, что они могут блокануть весь реактор, если их удерживать across .await points, кто-то услышал только "блокануть весь реактор", и теперь они прям как под каким-то табу. Кто-то виде в асинхронщине обычный Mutex, и сразу крик "О нет, оно заблкоирует всё!".
KR
Это не лично к тебе претензия. Я просто на это дело постоянно натыкаюсь контрибьютя во всякие либы и даже просто листая их issue.
IL
@tyranron А каким образом обходится проблема блокировки потока?
KR
@tyranron А каким образом обходится проблема блокировки потока?
Он не дедлочится.
KR
У тебя лок захватывается на минимально возможное время. Захватил, сделал всё нужно, отпустил. И области захвата не пересекаются, так как все под-капотные.
KR
Можешь просто проверить. Напихай туда кучу блокирующих операций и увидишь, что ты не блочишь сигналы.
IL
То есть, если я захвачу Mutable на запись, начну что-то делать 5 минут, и потом отпущу Mutable, то связанные с его сигналом таски не заблокируются? Заблокируются конечно. Токио попробует пополить где-нибудь фьючер, связанные с сигналом, и будет ждать все 5 минут вместе с тредом, в котором таска сидит
AI
Можешь просто проверить. Напихай туда кучу блокирующих операций и увидишь, что ты не блочишь сигналы.
Зависит от ОС не?
AI
Чето какую то статью читал от раст викли вроде
AI
Кто то в пух и прах разбивал спинлоки
AI
На линуксе
IL
Ребят, я не понимаю, при чем тут ОС? Стандартный RwLock обязан заблокировать тред, если RwLock начинают читать, когда в него кто-то пишет