19.10.2023 09:06
eao197 0 508 Источник

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

Для тех же, кто ни разу не слышал про SObjectizer, очень кратко: это относительно небольшой C++17 фреймворк, который позволяет использовать в С++ программах такие подходы, как Actor Model, Publish-Subscribe и Communicating Sequential Processes (CSP). Основная идея, лежащая в основе SObjectizer, — это построение приложения из мелких сущностей-агентов, которые взаимодействуют между собой через обмен сообщениями. SObjectizer при этом берет на себя ответственность за:

  • доставку сообщений агентам-получателям внутри одного процесса;

  • управление рабочими нитями, на которых агенты обрабатывают адресованные им сообщения;

  • механизм таймеров (в виде отложенных и периодических сообщений);

  • возможности настройки параметров работы перечисленных выше механизмов.

Составить впечатление о этом инструменте можно ознакомившись вот с этой обзорной статьей.

Новый тип message sink-а: transform_then_redirect

Принципиальным нововведением релиза 5.8.0 были message sink-и: если раньше подписчиком для сообщения мог быть только агент, то сейчас можно сделать реализацию интерфейса abstract_message_sink_t и подписать на сообщение кого угодно. Подробнее об этой функциональности рассказывалось в предыдущей статье. Там же говорилось и о том, что со временем могут появиться неочевидные для нас применения message sink-ов...

Одно из таких применений не заставило себя ждать: issue #67: bind_and_transform. Пользователь хотел иметь возможность преобразовать одно сообщение в другое прямо в момент его отправки получателю. Допустим, у нас есть сообщение:

struct compound_data
{
   first_data_part m_first;
   second_data_part m_second;
};

Оно отсылается в mbox_A.

И есть агент F, который хочет получить не всё сообщение compound_data целиком, а только compound_data::m_first. Т.е. агент F хочет получить сообщение типа first_data_part:

class F : public agent_t
{
   ...
   void so_define_agent() override {
      so_subscribe_self().event([](const first_data_part & msg) {...});
   }
};

И вот тут возникает вопрос: как же сделать так, чтобы при отсылке сообщения compound_data в mbox_A произошло формирование сообщения first_data_part и его отправка напрямую агенту F?

Связать mbox_A с собственным mbox-ом агента F не сложно, для этого есть вспомогательные классы single_sink_binding_t и multi_sink_binding_t:

const so_5::mbox_t mbox_A = ... // Получение mbox-а для compound_data.
const so_5::mbox_t mbox_F = ... // Получение mbox-а агента F.

so_5::multi_sink_binding_t<> binding;
binding.bind<compound_data>(mbox_A, so_5::wrap_to_msink(mbox_F));

Но такая связь доставляет агенту F исходное сообщение compound_data, тогда как нужно доставить только compound_data::m_first.

Т.е. нужно трансформировать исходное сообщение в новое сообщение другого типа.

И тут можно вспомнить, что в одном месте в SObjectizer подобная трансформация уже есть. Она является частью механизма защиты агентов от перегрузки:

class message_limits_demo final : public so_5::agent_t
{
public:
   message_limits_demo(context_t ctx)
      : so_5::agent_t{ ctx +
            // Говорим SObjectizer-у, что если количество
            // ждущих в очереди сообщений типа compound_data
            // будет больше 3-х, то новые сообщения нужно
            // преобразовать и переслать на другой mbox.
            limit_then_transform(3u, [this](const compound_data & msg) {
               return so_5::make_transformed<first_data_part>(
                  // Куда отсылать.
                  new_destination_mbox(),
                  // А это параметры для конструирования нового
                  // экземпляра сообщения first_data_part.
                  msg.m_first);
            })
            + ... }
       {}
...
};

Т.е. у нас в SObjectizer уже есть специальный тип so_5::transformed_message_t<Msg> и вспомогательная функция so_5::make_transformed<Msg, ...Args> предназначенные для преобразования сообщений с их последующей переадресацией. Так почему бы этим не воспользоваться?

В результате появилась вспомогательная функция so_5::bind_transformer, которая позволяет связать лямбду-трансформатор с сообщением из конкретного mbox-а. Благодаря bind_transformer наша задача решается следующим образом:

const so_5::mbox_t mbox_A = ... // Получение mbox-а для compound_data.
const so_5::mbox_t mbox_F = ... // Получение mbox-а агента F.

so_5::multi_sink_binding_t<> binding;
so_5::bind_transformer(binding, mbox_A,
   [mbox_F](const compound_data & msg) {
      return so_5::make_transformed<first_data_part>(mbox_F, msg.m_first);
   });

Интересное впечатление оставила реализация этой фичи: по субъективным ощущениям (учет времени, понятное дело, не велся) проектирование и реализация заняла всего лишь около 1/10 от всех затрат. Т.е. на тестирование и документирование полученной реализации ушло чуть ли не на порядок больше времени. Да еще и при разработке тестов удалось свалить VC++ в internal compiler error, чего уже давненько на нашем коде видеть не приходилось ???? В общем, отличный пример того, что "сделать хорошо" (т.е. с тестами, примерами, описаниями) обходится реально в десять раз дороже чем "просто сделать".

Методы agent_t::so_this_agent_disp_binder() и agent_t::so_this_coop_disp_binder()

В класс so_5::agent_t было добавлено два метода, которые дают доступ к disp_binder-ам, связанным с агентом и его кооперацией. Потребоваться это может при создании дочерних коопераций.

Допустим, мы создаем родительскую кооперацию со thread_pool-диспетчером:

// Этот агент будет затем создавать дочерние кооперации.
class parent_agent final : public so_5::agent_t {
   ...
};

// Регистрируем родительскую кооперацию.
env.introduce_coop(
   // Этот диспетчер будет использоваться для родительской кооперации
   // по умолчанию (т.е. если агент не привязан к какому-то другому
   // диспетчеру явно, то будет использоваться этот диспетчер).
   so_5::disp::thread_pool::make_dispatcher(env, 8u).binder(),
   [&](so_5::coop_t & coop) {
      // Этот агент будет использовать собственный диспетчер.
      coop.make_agent_with_binder<parent_agent>(
         so_5::disp::one_thread::make_dispatcher(env).binder(),
         ...);

      // Этот агент будет привязан к thread_pool-диспетчеру
      // кооперации, поскольку собственного disp_binder-а ему
      // не дали.
      coop.make_agent<worker>(...);

      ... // Создание остальных агентов родительской кооперации.
   });

Нам нужно, чтобы новые дочерние кооперации были привязаны к тому же thread_pool диспетчеру, который использовался и для родительской кооперации. Сейчас для этого достаточно воспользоваться новым методом agent_t::so_this_coop_disp_binder():

void parent_agent::make_new_child_coop() {
   so_5::introduce_child_coop(*this,
      // Новая кооперация будет использовать тот же диспетчер,
      // что и родительская кооперация.
      so_this_coop_disp_binder(),
      [&](so_5::coop_t & coop) {
         ... // Наполнение дочерней кооперации.
      });
}

Метод so_this_agent_disp_binder() возвращает disp_binder, который использовался для агента. И этот disp_binder может отличаться от disp_binder-а кооперации. Так, если в нашем примере мы напишем:

void parent_agent::make_new_child_coop() {
   so_5::introduce_child_coop(*this,
      // Новая кооперация будет использовать тот же диспетчер,
      // что и этот конкретный агент.
      so_this_agent_disp_binder(),
      [&](so_5::coop_t & coop) {
         ... // Наполнение дочерней кооперации.
      });
}

то дочерняя кооперация будет привязана не к thread_pool-диспетчеру родительской кооперации, а к one_thread-диспетчеру агента parent_agent. Что, очевидно, даст принципиально другой эффект.

Нужно сказать, что эту фичу у нас первый раз попросили довольно давно, еще в 2020-ом году. Так что ждать, как и предсказывала народная мудрость, пришлось три года ????

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

Однако не так давно, в версии 5.7.5, для устранения проблем с преждевременным удалением объектов агент получил disp_binder в собственное владение. Так что теперь реализация so_this_agent_disp_binder() стала тривиальной, что и было использовано при работе над версией 5.8.1.

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

Исправили то, на что долго не обращали внимание

В процессе работы над so_5::bind_transformer был выявлен досадный недочет на который никто в течении многих лет не обращал внимания: метод limit_then_transform нельзя было использовать с мутабельными сообщениями. Т.е. написать вот так:

class message_limits_demo final : public so_5::agent_t
{
public:
   message_limits_demo(context_t ctx)
      : so_5::agent_t{ ctx +
            // Говорим SObjectizer-у, что если количество
            // ждущих в очереди сообщений типа compound_data
            // будет больше 3-х, то новые сообщения нужно
            // преобразовать и переслать на другой mbox.
            limit_then_transform<so_5::mutable_msg<compound_data>>(3u,
               [this](compound_data & msg) {
                   return so_5::make_transformed<first_data_part>(
                      // Куда отсылать.
                      new_destination_mbox(),
                      // А это параметры для конструирования нового
                      // экземпляра сообщения first_data_part.
                      std::move(msg.m_first));
               })
            + ... }
       {}
...
};

до версии 5.8.1 было просто нельзя: возникла бы ошибка времени компиляции.

Как же так получилось, что этой проблеме уже много лет, а ее до сих пор никто не обнаружил?

Сперва мы недоглядели, потом никто не использовал limit_then_transform для мутабельных сообщений. Как-то так.

Но теперь нашли и исправили. Лучше поздно...

Заключение

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

Так что милости прошу озвучивать свои хотелки в issues или в discussions на GitHub-е. Или же в Google-группе.

Кстати говоря, если вам чего-то не хватает в SObjectizer-е, то можно заглянуть в проект-компаньон so5extra, мы там собрали разные полезные вещи, которые не хотели помещать в ядро SObjectizer-а.

С большим удовольствием упомяну серию статей о SObjectizer, которую начал публиковать Марко Арена (кто-то может знать его по Italian C++ Community). Найти эту серию можно в блоге Марко или на сайте dev.to. Мне самому было очень интересно читать написанные им статьи, как будто смотришь на давно привычные тебе вещи совсем с другой стороны. Так что рекомендую. На данный момент опубликовано три части, но это только начало.

И совсем в завершении, на правах саморекламы: изобретаю велосипеды для себя, могу изобрести и для вас.

Комментарии (0)