@Mkkt_Bkkt, а я ведь правильно понимаю, что lazy в принципе

Question

pro.cxx

magras

@Mkkt_Bkkt, а я ведь правильно понимаю, что lazy в принципе

реализует идею structured concurrency?

#c++ #embedded #programming #russian

0

24.04.2022

8 ответов

28 просмотров

Arelav

Пример кстати хреновый, так как это оверхед именно фьюч которые в стандартной библиотеке. Плюс они все равно так или иначе нужны для представления асинхронных, уже запущенных вычислений, это нужно например для таких алгоритмов как WhenAny Ну и вот пример бенчмарков нормальных фьюч и можно видеть насколько в стл все печально https://github.com/YACLib/Bench/tree/master/future/result/i7-11850H

0

24.04.2022

magras Автор вопроса

Arelav
Ну типо того, ну там ещё комбинаторы нужны, иначе ...

Комбинаторы это хорошо, но они не влият на основную идею structured concurrency (как ее вижу я) - строгую вложенность лайфтаймов корутин. Ну и конкретно std::executors до сих пор не поддерживает корутины из-за отсутствия отмены. На это жалуется и lazy, и executors.

0

24.04.2022

Arelav

magras
Комбинаторы это хорошо, но они не влият на основну...

Ну when_any like ее портит, идею в смысле, ну то есть оно вообще не вписывается нормально в structured concurrency. Там есть вариант с быстрой отменой всего что после первого, но такое себе на практике. Есть вариант с написанием асинхронной части поверх ленивой. std::execution поддерживает и отмены и корутины, по крайне мере если судить по libunifex, возможно не так как кому то хочется но это другой вопрос

0

24.04.2022

magras Автор вопроса

Arelav
Ну when_any like ее портит, идею в смысле, ну то е...

Я не уверен что знаком с последней ревизией, но проблема executors именно в том, что в них заложена отмена, а в корутины нет. В результате конечно можно обернуть корутину и просто игнорировать отмены, но я не готов назвать это поддержкой корутин. When_any, да, наверное это хороший пример демонстрирующий проблему structured concurrency подхода.

0

24.04.2022

Arelav

magras
Я не уверен что знаком с последней ревизией, но пр...

Поддержка корутин в том что sender awaitable, ну и в таком виде соорудить task like класс тривиально. А отмен на уровне sender условно в том что есть set_done + stop_token. И это же точно также работает внутри корутин. Например делает co_await в скедулер который уже остановлен и отменяешь всю последующую цепочку. (Кстати вроде в каких то из последних ревизий заменили set_done на set_canceled (вроде бы после доклада Ниблера)0)) Я в общем не вижу разницы написания с std::execution в колбечном then стиле, и корутинном где мы можем использовать co_await для асинхронного ожидания. Ну из плюсов линейный код, из минусов оверхед

0

24.04.2022

magras Автор вопроса

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

0

24.04.2022

Kelbon

magras
Все верно, но пока это обвязка внешняя, это создас...

стандартизация в расте )))))

0

24.04.2022

Arelav · Accepted Answer

Arelav

Ну типо того, ну там ещё комбинаторы нужны, иначе сложно что-то написать, std::execution собственно про это в том числе, просто там стали делать не через корутины, а по сути колбеки, которые могут работать с корутинами

0

24.04.2022

170 похожих чатов

@Mkkt_Bkkt, а я ведь правильно понимаю, что lazy в принципе

8 ответов

Похожие вопросы