Корутины C++

[chabapok]

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

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

int t = co_await foo();

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

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

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

Comments

[vak]

Корутины полезная фича. Интересно, что изобрели их в 60-е, а потом надолго забыли. Но понять интерфейс к ним - голову сломать можно. Я сбацал симулятор на корутинах - очень эффективно выходит.

https://vak.dreamwidth.org/756289.html
https://vak.dreamwidth.org/756930.html
https://vak.dreamwidth.org/757005.html
https://vak.dreamwidth.org/757609.html

[chabapok]

мне вот это сильно помогло https://www.youtube.com/watch?v=bRthJk8pKjw
И ссылки, которые идут по ходу дела.

"очень много скрытой механники" - говорит лектор

[juan_gandhi]

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

[chabapok]

ими очень удобно пользоваться когда у тебя есть много операций, которые делает не твоя программа а кто-то другой, а тебе надо просто результаты этих операций.
В этом случае ты пишешь так, как будто это обычный "линейный" код. А под капотом оно не блокируется, не запускает миллион потоков.
Очень удобная штука.

[juan_gandhi]

И эти потоки будут вызывать мой код в процессе? (Это то, что называлось корутинами (а также копрограммами) в древние времена.)

[chabapok]

немножко неясен ваш вопрос - какие "эти"?

то что раньше называлось корутинами и сопрограммами, то и сейчас называется. Если вы не видите преимущества - тут 2 варианта-антогониста:

1. может просто ваш круг задач не предполагает надобности в этом инструменте. Если это так, то они действительно ненужны.

2. вы привыкли и просто не хотите разбираться с чем-то новым. Мол, задачи решаемы старыми методами - ну и славненько, а разбираться некогда или лень.

Скорей всего, у вас вариант 1. Потому что, когда много внешних событий, то без корутин их разруливать реально тяжело, получается "макаронный код", куча функций, как они связаны между собой сразу неясно, алгоритм не просматривается, все глючит. И поэтому обычно человек, ознакомившийся с корутинами скажет "оо! это то что надо для моих задач!".

[juan_gandhi]

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

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

[chabapok]

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

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

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

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

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

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

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

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

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

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

[juan_gandhi]

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

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

[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 раз отладил и забыл.

[juan_gandhi]

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

[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.]

<p>предполагается, что "скачать" возвратит байтовый массив, или какой-то объект с картинкой. таймаут возвратит void, в простейшем случае. нажатие кнопки - в простейшем тоже возвратит void, ну или например возвратит, правой или левой кнопкой мышки нажато.</p> <p>И вот оно общение: я прошу "дай картинку" - а мне через какое-то время ее возвращают, или говорят "сорри, таймаут/кнопка отмены". Но при этом код я пишу, как будто последовательный, что существенно его упрощает и делает наглядным.</p> <p>Чуть сложней дело обстоит с генераторами. Их вроде доделали полностью в с++23. А может и в 20, точно не скажу.</p> <p>Вы вроде скалу знаете? Помоему в скале генераторы есть - но я не уверен. Когда-то очень давно читал книжку по скале - но не более того. Генератор это почти то же самое, что поток данных, только каждая следующая порция данных приходит через неопределенное время. Условно псевдокод:</p> <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> <p>Мы сказали генератору "сделай нам 300 значений с паузой 4 сек между ними" и каждый вызов gen() как бы продолжает исполнение сопрограммы дальше, а каждый co_yield это почти как co_return: возвращает значение, только это не полностью выход, а просто приостановка+возврат значения, с возможностью потом продолжить дальше. Тут, кстати, я не знаю, что будет, когда оно досчитает до 300. Этот псевдокод просто не демонстриует, что должно быть. Как правильно завершить, я не знаю. С генераторами я плотно не разбирался. Понятно, что там есть некоторый механизм, чтобы понять, что генератор окончил работу.</p> <p>Генераторы - штука специфическая, как по мне оно нужно сильно реже. Я совершенно точно хочу нормальную либу для сопрограмм в qt, и чтобы в ней были комбинаторы (типичное использование - для одновременного запуска сопрограммы и ее таймаута). А вот куда приложить генераторы - так навскидку я не знаю. Или у меня нет таких задач - или я не привык мыслить такими категориями. Возможно, таймер с постоянным периодом имеет смысл делать на базе генератора а не как корутину, просто чтобы реже делало аллокации/деаллокации. Ну то есть, штука интересная - но куда ее совать.</p>

[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).

[lxe]

Почему двенадцать, каких двенадцать? Меняется местами стек, that's it. OS это постоянно делает прозрачным для пользователя образом.

[chabapok]

В с++20 корутинах не меняется местами стек.

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

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

Это все надо как-то разруливать, и есть сколько-то точек, в которых ты должен все это поведение описать.

[lxe]

Пчаль. Я думал, на файбрах сделали, а теперь есть два механизма с нетривиальным взаимодействием.

[rampitec]

Вот у тебя там много умных комментеров. Это отлично! Как человек, который не первое десятилетие пишет компилер под SIMT, я тебе говорю: у меня мозг в клочья. Все что что ты хлотел спросить про шизфорению и боялся спросить. Это мой индастри стандарт. А корутины тут детский сад.