Корутины (модное слово)

[Пантер]

А я не хочу тратить свое время, чтобы объяснять элементарные вещи человеку, которому лень самому разобраться. Я с радостью делал это много раз для джунов, которые еще не умеют что-то самостоятельно выяснять, но ты-то не джун. Не трать наше время, а иди и сам разбирайся.

[Igors]

Нет никаких ниток, всё в одном потоке делается.

Так быть не должно, это противоречит идее асинхронности

Считайте что co_await делает внутри setjump/longjump в разные куски программы, такой goto. Как оно "у ей внутре" устроено - вопрос отдельный, но логика примерно такая - она как-то сохраняет текущий фрейм и позволяет к нему вернуться.

Ну вот мы запустили корутину и продолжаем выполняться. Нужен longjump чтобы вернуться, но мы же его не пишем сами. Кто (и в какой момент) его аызывает/реализует?

[Igors]

А я не хочу тратить свое время, чтобы объяснять элементарные вещи человеку, которому лень самому разобраться. Я с радостью делал это много раз для джунов, которые еще не умеют что-то самостоятельно выяснять, но ты-то не джун. Не трать наше время, а иди и сам разбирайся.

Лично Вас я не приглашал, и ничего не хочу от Вас получить Также никаких планов юзать корутины у меня нет, просто интересно что за фишка такая модная и что она делает. Почему мы об этом не можем поговорить? И чего Вы злитесь? 

[Old]

Нет никаких ниток, всё в одном потоке делается.

Так быть не должно, это противоречит идее асинхронности

Что за глупость?
Асинхронность и многопоточность это перпендикулярные понятия, никак не связанные. Может быть асинхронно в одном потоке и синхронно в разных.

[Авварон]

Ну вот мы запустили корутину и продолжаем выполняться. Нужен longjump чтобы вернуться, но мы же его не пишем сами. Кто (и в какой момент) его аызывает/реализует?

Компилятор, когда видит co_await. Он выделяет память (в куче) под текущий фрейм сохраняет туда контекст регистры что ему надо и делает setjump.
Когда где-то кто-то зовет handle.resume(), он восстанавливает данные из фрейма и делает переход в корутину (longjump).
Не факт что оно реализуется именно через эти функции, но я других способов не знаю, поэтому мне проще думать в терминах этих функций.
В целом, никто не мешает написать свой джамп, наверное.

[Old]

Компилятор, когда видит co_await. Он выделяет память (в куче) под текущий фрейм сохраняет туда контекст регистры что ему надо и делает setjump.
Когда где-то кто-то зовет handle.resume(), он восстанавливает данные из фрейма и делает переход в корутину (longjump).
Не факт что оно реализуется именно через эти функции, но я других способов не знаю, поэтому мне проще думать в терминах этих функций.
В целом, никто не мешает написать свой джамп, наверное.

Бэкенд там очень простой, вот на примере ucontext небольшая демка: https://gist.github.com/DanGe42/7148946
В этом примере используются системные сигналы для прерывания сисколов и переключения контекста, но в самом простом случае достаточно одного swapcontext, он все и делает.

[Авварон]

Да, вы правы, есть более продвинутый набор функций https://ru.wikipedia.org/wiki/Setcontext

[Igors]

Ну вот мы запустили корутину и продолжаем выполняться. Нужен longjump чтобы вернуться, но мы же его не пишем сами. Кто (и в какой момент) его аызывает/реализует?

Компилятор, когда видит co_await. Он выделяет память (в куче) под текущий фрейм сохраняет туда контекст регистры что ему надо и делает setjump.
Когда где-то кто-то зовет handle.resume(), он восстанавливает данные из фрейма и делает переход в корутину (longjump).
Не факт что оно реализуется именно через эти функции, но я других способов не знаю, поэтому мне проще думать в терминах этих функций.
В целом, никто не мешает написать свой джамп, наверное.

Вопрос был "кто (и в какой момент)", а не "как" - это действительно технические подробности второго плана. Судя по этому примеру

Код

C++ (Qt)
        while (true) {
            qDebug() << "entering loop";
            co_await qtcoro::make_awaitable_signal(changeTimer, &QTimer::timeout);
            qDebug() << "awaited";
            cr.changeColor();
        }
       ....

Упр-е возвращается на точку "awaited" при выходе (или попытке выхода) из области видимости co_await (тело while). Как если бы co_await вернула какую-то футуру и по окончании итерации while сработал бы ее деструктор. И вот там задача парится до упора и выполняется переход. Др вариантов здесь не видно, больше заставлять main прыгать просто некому. Но меня смущает что это нигде не написано  

Понятно что должны быть и др средства для "ручного" упр-я, но тогда co_await должен какую-то цацку вернуть

[Авварон]

Нет, co_await просто делает выход из лямбды сразу же. Он создал объект корутины в куче (для дальнейшего продолжения), сохранил в этот объект контекст и вышел, передав управление обратно в main().
Когда сигнал дернул handle.resume() (смотрите гитхаб как реализован make_awaitable_signal), компилятор восстановил контекст и передал управление на инструкцию следующую за co_await (блин как бесит этот префикс co_, вот нельзя было сделать по-человечески)

[Igors]

Нет, co_await просто делает выход из лямбды сразу же. Он создал объект корутины в куче (для дальнейшего продолжения), сохранил в этот объект контекст и вышел, передав управление обратно в main().

То "first pass"

Когда сигнал дернул handle.resume()..

Вот я и интересуюсь "когда" - само собой это ведь не случится если main продолжил нормальное выполнение после "first pass"

Др словами если main (поток создающий задачи) не блокирован (для этого все и городилось) - то значит он может делать что угодно, и никто "извне" не заставит его сделать переход

[Авварон]

Когда мы создали корутину, мы подписались на сигнал, который дернет resume(). Когда-нибудь. Может быть.

[Igors]

Когда мы создали корутину, мы подписались на сигнал, который дернет resume(). Когда-нибудь. Может быть.

Надеюсь это не "системный" сигнал линуха и не прерывание. А Qt сигналы и все остальное должны получить упр-е. Как оно к ним придет? Тот же фрагмент

Код

C++ (Qt)
       while (true) {
            qDebug() << "entering loop";
            co_await qtcoro::make_awaitable_signal(changeTimer, &QTimer::timeout);
            qDebug() << "awaited";
            cr.changeColor();
        }
 

Везде утверждается (и подчеркивается) что "создатель" (main) "не блокирован". Значит после создания он получит упр-е и перейдет к следующей итерации while.  И что, он будет хрюкать задачи бесконечно? Конечно нет, наоборот, фрагмент намекает что вся возня с таймером замкнута в теле while. Тогда кто инициирует "second pass"? Таймер (когда-то) дернет? А как он получит упр-е? Ведь пока мы крутим while - событийный цикл отрезан.

Здесь неплохо описано, это тот самый случай что Вы говорите. Но это не согласуется с примером выше

[Авварон]

Внимательно посмотрите на вывод который я написал выше. Встретив co_await мы вышли из лямбды и ушли в эвентлуп. Никто не крутит цикл вечно, мы крутимся в эвентлупе пока не придет сигнал от таймера. Когда он приходит, мы возвращаемся в луп, делаем 1 итерацию, и снова выходим в кутешный эвентлуп. И так пока не надоест.
co_await не блокирует (как waitForFinished у QFuture), он отдает управление коду, вызвавшему корутину. На первой итерации это main(), на последующих - сигнал от таймера.

[Racheengel]

Типичный пример "бездумного запуска в др потоке" Улыбающийся Если мы все равно "ждем-с", то надо было в main и выполнять, периодически вызывая processEvents, чем кстати и занимается QProgressDialog

Качалка не обязательно умеет сигналы и ивенты. Она может быть блокирующим вызовом, и диалог придется отрисовывать по таймеру.
Вот кстати хороший пример, где не спасет ни processEvents, ни корутина.

[Igors]

Внимательно посмотрите на вывод который я написал выше. Встретив co_await мы вышли из лямбды и ушли в эвентлуп. Никто не крутит цикл вечно, мы крутимся в эвентлупе пока не придет сигнал от таймера. Когда он приходит, мы возвращаемся в луп, делаем 1 итерацию, и снова выходим в кутешный эвентлуп. И так пока не надоест.
co_await не блокирует (как waitForFinished у QFuture), он отдает управление коду, вызвавшему корутину. На первой итерации это main(), на последующих - сигнал от таймера.

Да, так "все сходится", спасибо за разъяснения. Я неверно понял "не блокируется" - стало быть, упр-е возвращается вызывающему. В действительности main пошел заниматься др делами и вернулся только после того как задача выполнена.

Качалка не обязательно умеет сигналы и ивенты. Она может быть блокирующим вызовом, и диалог придется отрисовывать по таймеру.
Вот кстати хороший пример, где не спасет ни processEvents, ни корутина.

В случае "черного ящика" да