Модель Акторов и C++: что, зачем и как?

По молодежному сейчас это называется хаб:
https://habrahabr.ru/hub/erlang/

слишком мутное описание, чтобы из него можно было что-то почерпнуть об алгоритме.

Так описания алгоритма и не было. Речь о том, что когда идет интенсивный поток заявок, а обработка каждой заявки занимает очень небольшое время, то на практике очень хорошо зарекомендовал себя подход Disruptor.

Есть ли в SObjectizer статическая типизация агентов? Как это сделано у Вас?

Не понятно, что подразумевается под статической типизацией. Посмотрите пример из статьи. Метод fixed_stack::on_push будет вызван только для сообщения push, ни для какого другого сообщения его использовать не получится. Возможно это как раз посредством статической типизации.

Вероятно, вы под статической типизацией понимаете что-то другое. Например, невозможность отправить агенту сообщение типа A, если агент в нем не заинтересован. Если так, то этого в SObjectizer нет. Поскольку на практике с такими задачами не встречались. Где это может потребоваться?

Подразумевается, что актор может быть как функцией, так и классом. К чему требовать классы там, где достаточно лябды?

Прекрасно, нет проблем. Можно так:

class onliner_demo final : public so_5::agent_t {
public :
  onliner_demo(context_t ctx) : so_5::agent_t(std::move(ctx)) {
    so_subscribe_self()
      .event( &onliner_demo::event_A )
      .event( &onliner_demo::event_B );
  }
private :
  void event_A(const A &) {...}
  void event_B(const B &) {...}
};

Можно так:

auto coop = env.create_coop("demo");
auto onliner_demo = coop.define_agent();
onliner_demo.event( onliner_demo, [](const A &) {...});
onliner_demo.event( onliner_demo, [](const A &) {...});

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

Соответственно, вне зависимости от вида оформления агента ему доступны все, что доступно агенту (подписки, привязка к диспетчерам и т.д.).

не всегда возможно запихнуть всё приложение в модель акторов (gui, например), поэтому необходим тип акторов, который живёт «вовне» (scoped_actor) и управляется внешним event-loop

Тут непонятно зачем такие сущности обзывать акторами и делать для них какие-то специальные варианты. Либо есть актор, который привязывается к соответствующему диспетчеру (а диспетчер можно сделать так, чтобы он работал на GUI-нити или на другой нити со своим event-loop-ом). Либо это вообще не актор, а просто внешняя сущность, которой нужно тем или иным образом с акторами взаимодействовать. Опять же, это решается без выделения особых типов акторов.

Для работы внутри системы акторов также вохможны 2 ситуации:
— работа, основанная на сообщениях от других акторов (event_based_actor)
— работа, требующая ручного управления событиями внутри актора (сокеты, железо, бд и тп) (blocking_actor)

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

В SObjectizer контекстами управляет диспетчер, к какому агента привяжут, так он и будет работать. Нужен агенту эксклюзивный контекст — он привязывается либо к active_obj-диспетчеру, либо к собственному one_thread-диспетчеру. При этом внешний вид актора и его внутреннее поведение никак не меняется.

В SObjectizer настолько прост, что в нём ненужно разбираться?

Люди говорят, что проще, чем CAF.