Линеаризуем асинхронный код с помощью корутин

Если вы сделаете member-function корутиной вы тоже ожидаете, что поля класса скопируются в coroutine frame?
Дискуссия о том, чтобы как-то улучшить статус-кво, как я понимаю заглохла: https://github.com/GorNishanov/coroutines-ts/issues/32

А про искуственную сложность, не понял, в чем там искуственность.

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

Хотя даже если взять ваш первоначальный пример:

    abActor.getA(ABActor::GetACallback(*this, [this](int a) {
        abActor.getB(ABActor::GetBCallback(*this, [a, this](int b) {
            abActor.saveAB(a - b, a + b, ABActor::SaveABCallback(*this, [this](){
                abActor.getA(ABActor::GetACallback(*this, [this](int a) {
                    abActor.getB(ABActor::GetBCallback(*this, [a, this](int b) {
                        std::cout << "Result " << a << " " << b << std::endl;
                    }));
                }));
            }));
        }));
    }));

то непонятно зачем там все это. Вот обращение к некому ABActor::GetACallback оно зачем? И сама запись getA(ABActor::GetACallback()) она какая-то странная. Как будто вы намеренно выставляете напоказ все кишки своего актора.

По идее, вам нужно сделать запрос 'GetA' к актору A, а когда он на этот запрос ответит, вам нужно среагировать на ответ. Что, по идее, должно записываться как-то так (если уж у вас такая тяга к коллбэкам):

send<GetA>(A).then([](int a) {... /* Обработка ответа от A */ });

Ну или так:

A.send<GetA>().then([](int a) {... /* Обработка ответа от A */ });

Без всяких дополнительных ABActor::GetACallback.

А про искуственную сложность, не понял, в чем там искуственность.

Ok, в результате спора в комментариях я лучше понял что именно меня смущает в вашей статье. Попробую эти соображения сформулировать.

Первое. Необходимость ручного вызова GetACallback/GetBCallback/etc. Дело в том, что когда речь заходит об акторах, то для акторов thread-safety должна обеспечиваться автоматически самим фреймворкам. Т.е. когда актор A что-то осылает актору B, то актор B гарантированно будет обрабатывать входящее сообщение на своем (и только своем контексте). Тоже самое происходит и с ответом от B к A: этот ответ так же гарантировано будет обрабатываться строго на контексте A. И для обспечения этих свойств пользователю акторного фреймворка делать ничего не нужно.

У вас же в примере thread-safe полуавтоматически обеспечивается только от A к B. Тогда как для ответного сообщения от B к A требуется ручная работа. Именно поэтому программисту вручную приходится вызывать GetACallback при вызове getA.

Как по мне, было бы лучше, если бы getA в таком случае имел бы вид:

A.getA(this, [this](auto a) {...});

вместо:

A.getA(GetACallback(this, [this](auto a){...}));

Именно вот эта потребность в ручном вызове GetACallback и выглядит для меня как выставление "кишок" наружу. Хотя от этих кишок можно было бы легко избавится делая вызов GetACallback прямо внутри getA.

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

Давайте представим, что есть некая сущность S, предоставляющая тот или иной сервис. И есть сущность C, которая пользуется этим сервисом.

Сущность C хочет воспользоваться услугами S в асинхронном режиме. Т.е. сделать что-то типа:

void C::do_something() {
   async(some_context, [&S]{ S.get_service(); });
   ... // Продолжаем работу пока где-то еще S выполняет вызов get_service.
}

Здесь C асинхронно обращается к S.

Но вот собственно работа S::get_service может быть как синхронной (например, get_service выполняет какую-то CPU-bound активность типа шифрования данных или проверки подписи, перекодирования изображений и т.д.), так и асинхронной (например, get_service вызывает неблокирующую операцию записи данных в сокет, которая непонятно когда закончится).

И если S::get_service — это синхронная операция, то возврат ее результата через лямбду — это как-то странно. Можно, конечно, но странно. Тут бы что-то вроде future бы подошло. И код бы имел вид:

void C::do_something() {
   auto f = async(some_context, [&S]{ return S.get_service(); });
   ... // Продолжаем работу пока где-то еще S выполняет вызов get_service.
   f.get();
}

Ну или запись с then была бы вполне уместной: S.ask<get_service>().then(this, [](auto result) {...}).

А вот если вы говорите о случаях, когда сама S::get_service — это асинхронная операция, то тогда вызов callback-а вопросов не вызывает.

Так что если бы вы сделали упор на то, что в первую очередь важна асинхронность самого S::get_service, а не асинхронность обращения от C к S, то мне лично ваш замысел был бы лучше понятен. А так непонятно, на какую именно асинхронность нужно обращать внимание: на то, что C асинхронно обращается к S или на то, что S выполняет свою работу на собственном контексте исполнения только асинхронно.

Третье. Очень нехватает какой-то осмысленной работы внутри актора, который требует у abActor выполнения операций getA, getB и т.д. Т.е. если бы вы сами операции обозвали бы как-то предметно, типа receiveMessage, decryptMessage, storeMessage, да еще и эти операции выполнялись бы разными акторами, да еще если бы результаты этих операций хоть как-то бы анализировались бы… Типа:

mqClient.receiveMessage(this, [this](auto msg) {
   log_incoming(msg);
   if(encryptedMessage(msg)) {
     ++encrypted_stats;
     crypto.decryptMessage(msg.payload(), this, [this, &msg](const auto decrypted) {
       log_decrypted(decrypted);
       msg.setPayload(decrypted);
     });
   }
   db.storeMessage(msg, this, [this](auto result) {...})
});

Ну или что-то в этом духе.

То ваш пример воспринимался бы лучше, т.к. было бы понятно и сколько акторов участвует, и почему важно callback-и вызвать на контексте инициатора асинхронной операции.

Есть «акторный» подход к решению задач. Это один из подходов, не утверждается, что он единственно верный. Но он есть. И зачастую код с акторным подходом превращается в такую «мешанину» коллбэков.

Акторный подход как бы базируется на отсылке сообщений акторам. А у вас он именно что "акторный", т.к. вместо взаимодействия на сообщениях вы вручную диспетчируете вызовы конкретных коллбэков (с ручным же провязыванием этих коллбэков в цепочки).