A
думаю сделаю через него
Size: a a a
2020 August 06
V
А на FuturesUnordered кстати скорее всего не поправил просто или почему там WorkerResult
A
Vetro
А на FuturesUnordered кстати скорее всего не поправил просто или почему там WorkerResult
да, я забыл
V
👍
D
кстати эта проблема с анонимными возвращаемыми типами решится, когда допилят
https://github.com/rust-lang/rust/issues/63063
https://github.com/rust-lang/rust/issues/63063
A
но оно работает, я сейчас чекнул, Stream имплементится по итогу для FuturesUnordered в структуре
A
кстати эта проблема с анонимными возвращаемыми типами решится, когда допилят
https://github.com/rust-lang/rust/issues/63063
https://github.com/rust-lang/rust/issues/63063
ок
D
кстати эта проблема с анонимными возвращаемыми типами решится, когда допилят
https://github.com/rust-lang/rust/issues/63063
https://github.com/rust-lang/rust/issues/63063
типа такого можно будет делать:
type Kek = impl std::future::Future;
fn lol() -> Kek {
async {}
}
pub struct Wow(Vec<Kek>);
A
а когда стоит использовать
crossbeam::atomic::AtomicCell вместо std::sync::Mutex?D
дык у них же API принципиально разные
D
AtomicCell позволяет store/swap делать, а мутекс — полноценные мутабельные ссылки
V
а когда стоит использовать
crossbeam::atomic::AtomicCell вместо std::sync::Mutex?В асинке стандартный лочащий мутекс кстати не стоит использовать
(за исключением моментов когда лок не держится между .await точками)
(за исключением моментов когда лок не держится между .await точками)
A
Vetro
В асинке стандартный лочащий мутекс кстати не стоит использовать
(за исключением моментов когда лок не держится между .await точками)
(за исключением моментов когда лок не держится между .await точками)
а новые гайды на tokio.rs говорят обратное, если асинк, то не обязательно
tokio::sync::Mutex, а также что чаще всего проблемы с локами решаются не заменой мьютекса с одного на другойV
Ну вообще правильно говорят
Нет смысла от асинхронного мутекса, если его лок не держится между несколькими точками .await
Но и да, это просто в любом случае уже из разряда микрооптимизаций, кмк
Нет смысла от асинхронного мутекса, если его лок не держится между несколькими точками .await
Но и да, это просто в любом случае уже из разряда микрооптимизаций, кмк
V
Если вдруг из-за логики дедлок где-то - смена мутекса вряд ли поможет
D
ваще очень странный совет от токийцев, потому что вот это вот их
as long as contention remains low and the lock is not held across calls to .await легче лёгкого упустить из видуD
прям очень странно
D
токийский мутекс не блокирует экзекутор, а обычный — блокирует
D
это конечно становится актуальным только когда тасок в этом самом экзекуторе довольно много, но это по-моему дефолтный кейс
V
Обычный не блокирует экзекутор весь ведь
(только если он не однопоточный)
(только если он не однопоточный)