chabapok | Корутины C++

В С++20 появились корутины

task<int> foo(){ ... }

int t = co_await foo();

Штука удобная, а стандарт написан так, что реализацию можно подставить какую хочешь. Это удобно. Но основная проблема - говорят, что человек может одновременно держать в голове 5..6 сущностей, программист - 7..8. Для реализации движка корутин нужно около 12.

Так с наскоку разобраться, как оно там под капотом работает, тяжело. Вроде все понятно, начинаешь делать - начинаются странности. При помощи ютуб - более-мене реально, но тоже сложно.

Я попытался сделать asyc/await движок с qt-шной очередью событий. (знаю про qcoro, но мне хочется понять, как оно сделано. А еще в qcoro нет await_all/await_first, и некоторые другие вещи не поддержаны). За 1 вечер нормально движок не сделать.

Flat | Top-Level Comments Only

From:

juan_gandhi

"эти" - это потоки, которым мы что-то передали.
Так ещё два вопроса. Передаём ли мы callback (тогда всё в порядке), или та корутина знает мои точки входа (тогда бардак, чисто с топологических соображений). Вот этот второй вариант и привёл меня когда-то к выводу, что лучше не надо.

Погуглил на вики. Да, я сильно против. Топология получается хреновая. Если что сломалось, то дыру не найти, вообще говоря.

From:

chabapok

> "эти" - это потоки, которым мы что-то передали.

возможно, вопрос сформирован как-то некорректно. Я не понимаю, что спрашивается. Я попытаюсь ответить, но возможно это будет ответ невпопад:

В с++20 корутинах ты сам делаешь библиотеку(или готовую находишь), которая как тебе надо диспетчеризует исполнение по потокам, и в нужные момент зовет нужные континьюэйшены из нужных тебе потоков.

> Так ещё два вопроса. Передаём ли мы callback (тогда всё в порядке), или та корутина знает мои точки входа (тогда бардак, чисто с топологических соображений). Вот этот второй вариант и привёл меня когда-то к выводу, что лучше не надо.

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

Недостаток каллбеков в том, что когда у тебя много вложеных событий, то получается много вложенных каллбэкеов. И получается то, что назвали callback hell, и собственно ради отказа от callback hell эти корутины и придумали. В гугле вводите callback hell и тыкаете картинки, там будут примеры кода.

А если каждой асинхронной операции, например, нужен свой таймаут, а иногда таймаут нужен один на несколько операций, то там еще и ветвление асинхронное получается. Делал такое, больше не хочу. Это вообще жуть.

> Если что сломалось, то дыру не найти, вообще говоря.

На счет сишных корутин я не стану вообще ничего утверждать, т.к. почти не имел с ними дел, а только предварительно ознакомился. В kotlin корутины сделаны удобно, и библиотека уже есть. Я вообще не представляю, как сложно бы было некоторые вещи без них делать, но сама концепция вроде похожа на сишные.

Как таковой с++, даже без корутин, отлаживать мне тяжелей чем java/kotlin, поэтому понятно, что и с корутинами тоже будет тяжелей. Но если где-то какой-то баг понадобится искать - ну мне кажется, оценочно, что это так же тяжело будет, как и вообще все на с/с++. Поэтому я больше джаву-котлин люблю.

From:

juan_gandhi

А, ну так всё-таки обычные корутины. Если вынести на уровень микросервисов, то сервис А посылает что-то в точку сервиса Б, тот, подумав, посылает что-то в другую точку сервиса А - ну или с большим количеством участников.

Получаются обычные spaghetti. Которые нельзя алфавитно-топологически отсортировать. В которых может произойти бага, которую и теоретически невозможно локализовать. Это будет бюрократия, где не найти концов. (У нас в конторе примерно такая хрень, но у нас у разных групп сервисов репутации очень разные, и всегда можно свалить на "тех идиотов".)

From:

chabapok

да вроде наоборот оно задумывалось для "расспагечивания".

Наверное, или вы недопоняли суть, или я недопонял масштаб проблемы :)

Ну вот например, есть кнопка, и надо скачать последовательно 5 картинок с таймаутом. И если на кнопку нажали, то надо отменить скачку текущей скачиваемой картинки.

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

скачать("a.png", {
   скачать("b.png", {
      скачать("c.png", { 
         ....
      })
   })
})

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

Корутины все "выравнивают" и ты пишешь как будто код последовательный:

скачать("a.png")
скачать("b.png")
скачать("c.png")

А когда надо навесить таймауты и кнопки - то используешь комбинаторы:

то_что_завершится_первым( скачать("a.png"), таймаут(10сек), нажатие_кнопки)
то_что_завершится_первым( скачать("b.png"), таймаут(10сек), нажатие_кнопки)
то_что_завершится_первым( скачать("c.png"), таймаут(10сек), нажатие_кнопки)

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

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

При этом предполагается, что либу поддержки корутин ты 1 раз отладил и забыл.

From:

juan_gandhi

Ну, так-то всё норм; "скачать" не собирается разговаривать с тем процессом, который её позвал, пиная там что-нибудь, что он знает, что надо пинать. Я вижу тут иерархию; ну распаралеллена, и чо. Нормально.

From:

chabapok

предполагается, что "скачать" возвратит байтовый массив, или какой-то объект с картинкой. таймаут возвратит void, в простейшем случае. нажатие кнопки - в простейшем тоже возвратит void, ну или например возвратит, правой или левой кнопкой мышки нажато.

И вот оно общение: я прошу "дай картинку" - а мне через какое-то время ее возвращают, или говорят "сорри, таймаут/кнопка отмены". Но при этом код я пишу, как будто последовательный, что существенно его упрощает и делает наглядным.

Чуть сложней дело обстоит с генераторами. Их вроде доделали полностью в с++23. А может и в 20, точно не скажу.

Вы вроде скалу знаете? Помоему в скале генераторы есть - но я не уверен. Когда-то очень давно читал книжку по скале - но не более того. Генератор это почти то же самое, что поток данных, только каждая следующая порция данных приходит через неопределенное время. Условно псевдокод:

int foo(int max, int pause_seconds) {
  for(i=0; i

[Error: Irreparable invalid markup ('<max;>') in entry. Owner must fix manually. Raw contents below.]

предполагается, что "скачать" возвратит байтовый массив, или какой-то объект с картинкой. таймаут возвратит void, в простейшем случае. нажатие кнопки - в простейшем тоже возвратит void, ну или например возвратит, правой или левой кнопкой мышки нажато. И вот оно общение: я прошу "дай картинку" - а мне через какое-то время ее возвращают, или говорят "сорри, таймаут/кнопка отмены". Но при этом код я пишу, как будто последовательный, что существенно его упрощает и делает наглядным. Чуть сложней дело обстоит с генераторами. Их вроде доделали полностью в с++23. А может и в 20, точно не скажу. Вы вроде скалу знаете? Помоему в скале генераторы есть - но я не уверен. Когда-то очень давно читал книжку по скале - но не более того. Генератор это почти то же самое, что поток данных, только каждая следующая порция данных приходит через неопределенное время. Условно псевдокод: <pre> int foo(int max, int pause_seconds) { for(i=0; i<max; i++){ co_yield i; // "посылаем" очередное значение co await delay(pause_seconds); //и подождем } } int main(){ auto gen = foo(300, 4) for(;;) { println( co_await gen() ); } } </pre> Мы сказали генератору "сделай нам 300 значений с паузой 4 сек между ними" и каждый вызов gen() как бы продолжает исполнение сопрограммы дальше, а каждый co_yield это почти как co_return: возвращает значение, только это не полностью выход, а просто приостановка+возврат значения, с возможностью потом продолжить дальше. Тут, кстати, я не знаю, что будет, когда оно досчитает до 300. Этот псевдокод просто не демонстриует, что должно быть. Как правильно завершить, я не знаю. С генераторами я плотно не разбирался. Понятно, что там есть некоторый механизм, чтобы понять, что генератор окончил работу. Генераторы - штука специфическая, как по мне оно нужно сильно реже. Я совершенно точно хочу нормальную либу для сопрограмм в qt, и чтобы в ней были комбинаторы (типичное использование - для одновременного запуска сопрограммы и ее таймаута). А вот куда приложить генераторы - так навскидку я не знаю. Или у меня нет таких задач - или я не привык мыслить такими категориями. Возможно, таймер с постоянным периодом имеет смысл делать на базе генератора а не как корутину, просто чтобы реже делало аллокации/деаллокации. Ну то есть, штука интересная - но куда ее совать.

From:

juan_gandhi

С генераторами понятно; в любом случае вызванный процесс сохраняет состояние, для данного клиента, ну и. Kind of against the restful ideology, but it's ok.

Still, it's all pretty innocent. Not the kind of coroutines I knew, where entities call each other with no control regarding who can call whom (and why).