LINUX.ORG.RU

анонс: SObjectizer 5.3.0

 


2

6

SObjectizer — это реализация модели акторов для C++, позволяющая программировать на C++ с использованием работающих на разных нитях агентов, общающихся между собой посредством сообщений. SObjectizer существенно упрощает разработку событийно-ориентированных приложений, для параллельной и независимой обработки событий в которых требуется многопоточность и/или распределенность. SObjectizer использовался для создания как для мелких утилит, так и серьезных распределенных приложений, работающих под большой нагрузкой в режиме 24x7.

Последние несколько лет SObjectizer развивается на SourceForge как OpenSource проект под BSD-лицензией. Версия 5.3.0 является очередным существенным шагом по наращиванию возможностей SObjectizer при одновременном упрощении его использования.

В версии 5.3.0 произведены значительные улучшения:

  • добавлена возможность организации синхронного взаимодействия агентов: инициатор запроса может синхронно ожидать результата на объекте std::future, в то время как обработчик запроса работает обычным образом на своей рабочей нити;
  • более активно используются лямбда-функции, введенные в C++11. Например, теперь обработчики событий могут быть заданы посредством лямбда-функций, что позволяет уменьшить объем кода агентов;
  • добавлена возможность создавать ad-hoc агентов, формируя агента из лямбда-функций, а не описывая отдельный, унаследованный от so_5::rt::agent_t, класс;
  • доработана модель реагирования на выпущенные из обработчиков событий исключения.

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

Традиционный пример “Hello, World” теперь может быть записан вот так:

so_5::api::run_so_environment(
  []( so_5::rt::so_environment_t & env ) {
    auto coop = env.create_coop( "hello" );
    coop->define_agent().on_start( [&env]() {
      std::cout << "Hello, World" << std::endl;
      env.stop();
    } );
    env.register_coop( std::move( coop ) );
  } );
А более интересный пример ping_pong, где каждый агент работает на контексте своей собственной нити, вот так:
int pings_left = 10000;
so_5::api::run_so_environment(
  [&pings_left]( so_5::rt::so_environment_t & env )
  {
    struct msg_ping : public so_5::rt::signal_t {};
    struct msg_pong : public so_5::rt::signal_t {};

    auto mbox = env.create_local_mbox();
    auto coop = env.create_coop( "ping_pong",
       so_5::disp::active_obj::create_disp_binder( "active_obj" ) );
    coop->define_agent()
      .on_start( [mbox]() { mbox->deliver_signal< msg_ping >(); } )
      .on_event( mbox, so_5::signal< msg_pong >,
        [&pings_left, &env, mbox]() {
          if( --pings_left > 0 )
            mbox->deliver_signal< msg_ping >();
          else
            env.stop();
        } );
    coop->define_agent()
      .on_event( mbox, so_5::signal< msg_ping >,
        [mbox]() { mbox->deliver_signal< msg_pong >(); } );
    env.register_coop( std::move( coop ) );
  },
  []( so_5::rt::so_environment_params_t & params )
  {
    params.add_named_dispatcher( "active_obj", so_5::disp::active_obj::create_disp() );
  } );

Версия распространяется в виде сборки so-201407-00, в которую кроме SObjectzer 5.3.0 входит еще несколько SObjectizer-библиотек, предназначенных для разработки больших, распределенных приложений на основе SObjectizer, а именно:

  • so_log, служащая оберткой над ACE Logging и упрощающая логирование для агентов;
  • so_sysconf, позволяющая собирать большое приложение из маленьких кусочков, оформленных в виде dll/so-библиотек;
  • so_5_transport, оформляющая работу с TCP/IP соединениями в виде транспортных SObjectizer-агентов;
  • mbapi, являющаяся высокоуровневой библиотекой для обмена сообщениями между агентами или между компонентами распределенного приложения.

Релизная сборка может быть загружена с SourceForge в виде архива или же взята из svn-репозитория.

Wiki-раздел SObjectizer-а на SourceForge содержит более подробную информацию как об особенностях версии 5.3.0, так и о самом SObjectizer и его основах.

★★★★★

Какой-то сплошной синтаксический шум, как на этом вообще можно писать?

anonymous
()

Эталон плюсовой библиотеки. Кошмарный код, кошмарный api и кошмарная документация. Версия 5.3.

anonymous
()

Глаза, мои глаза! Серьёзно, у вас там премию дают за максимально нечитаемый код?

Gvidon ★★★★
()
Ответ на: комментарий от crowbar

для игр пойдет?

Смотря для каких.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от Gvidon

Глаза, мои глаза! Серьёзно, у вас там премию дают за максимально нечитаемый код?

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

eao197 ★★★★★
() автор топика
Ответ на: комментарий от false

Да это может быть даже похлеще буста будет

Похлеще буста не будет.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от ilammy

нити
многопоточность

И? В русскоязычной терминологии это уже давно устоявшиеся синонимы для threads и multitheading. Да и термин многопоточное приложение употребляется намного чаще, чем многонитевое.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от AlexVR

Вот теперь удалось прочитать первый пример :)

Примеров, на самом деле, много. Большинство из них в стиле старого-доброго «С с классами». Вот, один из них, вообще без новомодных изысков.

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

eao197 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

А что там за собиралки такие на рубях?

Mxx_ru — это такая заточенная под C++ штука, которая Ruby в качестве DSL использует. Раньше хостилась на RubyForge. Сейчас доступна как RubyGem.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Чем cmake не угодил?

Дык десять лет спокойно пользуемся, смысла переползать куда-то особо не было. Да и кодогенераторы, написанные на Ruby там элементарно подключаются.

Тем более, что cmake нифига не стандарт. Равно как и SCons, Boost.Jam, qmake, gyp и еще куча всего разного. Что не выбери, обязательно будут те, кто использует что-то еще.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

В C++ это нормально. Слов они боятся, поэтому многие вещи записываются символом (APL++, да). Кратко, круто, нечитабельно. Соответственно, на нём всё и выходит такое.

anonymous
()
Ответ на: комментарий от anonymous

Кошмарный код, кошмарный api и кошмарная документация.

А вы и дальше продолжайте программировать веб-сайтики.

anatoly
()
Ответ на: комментарий от anatoly

А вы и дальше продолжайте программировать веб-сайтики.

Голый libev будет читабельнее и быстрее этого говна.

bj
()
Ответ на: комментарий от anonymous

libcppa,

Такой же велосипед, как и SObjectizer.

boost::fiber,

Такое же ручное управление потоками выполнения и доступом к ресурсам, как и с нитями, со всеми вытекающими прелестями.

etc.

Как-то коротковат список оказался. Что в etc запишете?

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Спасибо, буду знать.

Если это ирония, то список ussues на гитхабе не может не радовать подходом к разработке.

bj
()
Ответ на: комментарий от bj

Если это ирония, то список ussues на гитхабе не может не радовать подходом к разработке.

Один критерий понятен. Еще что-нибудь?

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Еще что-нибудь?

Достаточно этого. Но стоит признать, если нужен будет кросплатформенный слой для доступа к фс, то возьму libuv. Во всех остальных случаях libev более чем хорош.

bj
()
Ответ на: комментарий от bj

Т.е. «школота» относилась не к заложенным в библиотеку концепциям, а к подходам к организации процесса разработки и сопровождения проекта?

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Гугл в помощь. Честно говоря, я не пользовался сабжем, но мне кажется, что он более примитивен, чем то, что есть уже. Тем более для 5ой версии.

anonymous
()
Ответ на: комментарий от anonymous

Гугл в помощь.

Отлично, что именно искать? По информации в Wikipedia, для C++ сейчас есть только две живые реализации акторов: SObjectizer и libcppa (все остальное заглохло где-то в районе 2012-го года в лучшем случае). Год назад еще Антони Уильямс анонсировал версию своей jss с поддержкой акторов, но больше об этом ничего не слышно. Да и сами акторы там очень простые.

Честно говоря, я не пользовался сабжем, но мне кажется, что он более примитивен, чем то, что есть уже.

Т.е. не читал, но осуждаю?

Кстати, если это вы упоминали boost.fibers, то ведь в Boost-е этой библиотеки нет, формальный review она не прошла. Во что она со временем трансформируется — еще вопрос.

Тем более для 5ой версии.

Первая цифра в номере — это скорее номер реинкарнации. SObjectizer реализует идеи, которые были сформулированы где-то в конце 1995-го. Первые три поколения назывались SCADA Objectizer (1, 2 и 3, соответственно) были сделаны под OS/2 между 1995-м и 2001-м. 4-я реинкарнация, уже под именем SObjectizer появилась в 2002-м. А пятая, тот самый SObjectizer-5, в конце 2010.

Все поколения были несовместимы между собой. Так, SO-4 и SO-5 — это совсем разные библиотеки. Перенос кода из SO-4 в SO-5 требовал его переписывания. Общие между всеми поколениями только базовые принципы: агенты с состояниями, асинхронные сообщения, диспетчеры.

Так что 5.3 — это гораздо ближе к 1.3 или к 0.3, кому как нравится. Нам удобнее было пользоваться нумерацией 4.4.0 и 5.3.0 вместо SO4-1.4.0 и SO5-1.3.0, тем более, что в ряде проектов SO-4 и SO-5 до сих пор мирно сосуществуют в рамках одного приложения.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Т.е. «школота» относилась не к заложенным в библиотеку концепциям, а к подходам к организации процесса разработки и сопровождения проекта?

Ты уже такой взрослый мужик и не понимаешь что последнее, как раз, самое важное? Очень мило.

bj
()
Ответ на: комментарий от no-such-file

Ты уже такой взрослый мужик и не понимаешь что последнее, как раз, самое важное? Очень мило.

Если это самое важное, то какие тогда претензии к subj?

eao197 ★★★★★
() автор топика
Ответ на: комментарий от no-such-file

А ещё перл ругают...

Комментаторов не поймешь :) Когда можно было писать только вот так:

class a_pinger_t : public so_5::rt::agent_t
{
public :
  a_pinger_t( so_5::rt::so_environment_t & env,
    const so_5::rt::mbox_ref_t & mbox,
    int pings_left )
    : so_5::rt::agent_t( env )
    , m_mbox( mbox )
    , m_pings_left( pings_left )
    {}

  virtual void so_define_agent()
  {
    so_subscribe( m_mbox ).event( &a_pinger_t::evt_pong );
  }

  virtual void so_evt_start()
  {
    m_mbox->deliver_signal< msg_ping >();
  }

  void evt_pong( const so_5::rt::event_data_t< msg_pong > & )
  {
    if( m_pings_left ) --m_pings_left;
    if( m_pings_left )
      m_mbox->deliver_signal< msg_ping >();
    else
      so_environment().stop();
  }
private :
  const so_5::rt::mbox_ref_t m_mbox;
  int m_pings_left;
};
они говорили «С++ такой С++»...

Стало можно писать еще и вот так:

coop->define_agent()
  .on_start( [mbox]() { mbox->deliver_signal< msg_ping >(); } )
  .on_event( mbox, so_5::signal< msg_pong >,
    [&pings_left, &env, mbox]() {
      if( --pings_left > 0 )
        mbox->deliver_signal< msg_ping >();
      else
        env.stop();
    } );
опять «С++ такой С++»...

:)))

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Так кресты-то никуда не делись. На C++ вообще нормально писать вряд ли можно в современном мире. Только унаследованный код, а новые проекты только в случае, если очень нужно.

anonymous
()
Ответ на: комментарий от eao197

Когда можно было писать только вот так:

Так и правда лучше.

опять «С++ такой С++»

Ну так криворукие примеры же. Начать с mbox_ref_t. Убил бы, блджад, ты ещё венгерскую нотоцию прикрути. Про const so_5::rt::event_data_t< msg_pong > & я вообще молчу. typedef - нет не слышал, трайты - а что это?

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Начать с mbox_ref_t.

Что не так с mbox_ref_t? Может вам еще и shared_ptr и unique_ptr не нравятся?

const so_5::rt::event_data_t< msg_pong > &

Ну и что, по вашему, с этим нужно сделать с помощью трайтов и тайпдефов?

eao197 ★★★★★
() автор топика
Ответ на: комментарий от no-such-file

Ну и вдогонку, просто убивает страсть некоторых людей наворачивать 100500 неймспейсов. Хочется сразу спросить у вас там что, конфликты имён внутри своего же велосипеда?

so_5::rt::so_environment_t &

Это что за атомный писец? so_5 - нахрена мне знать версию вашего велосипеда, лучше просто sobjectizer. rt - ну и нафига? so_environment_t - мы и так уже в неймспейсе so_5 заечем еще одно so_ ? зачем _t, какую информацию это мне даёт?

sobjectizer::environment - достаточная сигнатура для этого типа и не нужно ничего больше наворачивать.

no-such-file ★★★★★
()
Ответ на: комментарий от anonymous

На C++ вообще нормально писать вряд ли можно в современном мире. Только унаследованный код, а новые проекты только в случае, если очень нужно.

Ok, допустим, что так и есть. И ограничимся только рамками старых C++ проектов, которые нужно развивать, а переписать слишком долго и дорого. В этом случае что не устраивает?

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Если это самое важное, то какие тогда претензии к subj?

Первый признак плохого, негодного проекта — он старый и нет никакой обратной связи. Зато есть «концептуальный» код. То есть, он никому не нужен, окромя автора.

bj
()
Ответ на: комментарий от no-such-file

so_5 - нахрена мне знать версию вашего велосипеда,

Очевидно, что у библиотеки пять раз полностью менялся API.

bj
()
Ответ на: комментарий от no-such-file

Хочется сразу спросить у вас там что, конфликты имён внутри своего же велосипеда?

Типа того. Например, create_disp и create_disp_binder есть в нескольких неймспейсах внутри so_5.

so_5 - нахрена мне знать версию вашего велосипеда, лучше просто sobjectizer

Вам нахрен не нужно. Нам нужно, поскольку so_5 используется в одних и тех же проектах с so_4.

so_environment_t - мы и так уже в неймспейсе so_5 заечем еще одно so_ ?

Чтобы не писать полностью sobjectizer_environment_t. Просто environment неоднозначно, окружения могут быть разные.

зачем _t, какую информацию это мне даёт?

Это соглашение об именовании у нас такое. Для ленивых. Позволяет писать вот так:

agent_t agent;

Вместо:

agent some_agent;

А вообще споры по поводу стиля оформления кода в топку. Хотите одного стиля — в Java, C# или Go. Там есть стандарт и сама IDE за вас код форматирует. В С++ же нет единого общепринятого соглашения.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от bj

То есть, он никому не нужен, окромя автора.

Ну а вот это мы и хотим проверить. До сих пор усилия по его раскрутке практически не прикладывались.

Тем не менее, логики в вашем приравнивании разработчиков проектов к «школоте» не видно. Одних вы считаете «школотой» за то, что у них есть раскрученный проект, но которому не хватает организованности для своевременного исправления багов. Вторых за нераскрученный, хотя с исправлением багов там проблем нет.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Это соглашение об именовании у нас такое. Для ленивых. Позволяет писать вот так:

agent_t agent;

Вместо:

agent some_agent;

Про Agent agent вы не догадались? Мне лень писать каждый раз ещё 2 символа на каждый класс.

Просто environment неоднозначно, окружения могут быть разные

Чо правда? Т.е. вам даже 100500 неймспейсов не хватает?

so_5 используется в одних и тех же проектах с so_4.

Ну просто чума. А что у них разная функциональность или просто вы ещё не успели полностью переобуться на новую версию? (И что вы в одной ветке переходите?)

Например, create_disp и create_disp_binder есть в нескольких неймспейсах внутри so_5.

А должны быть в нескольких классах в одном неймспейсе. Как по вашему я должен сделать свой вариант? Копипастом?

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от no-such-file

Про Agent agent вы не догадались? Мне лень писать каждый ещё 2 символа на каждый класс

А мне лень нажимать shift чтобы использовать нотацию с заглавными буквами. Тем более, что названия типов автоматически дополняются даже vim-ом.

А что у них разная функциональность или просто вы ещё не успели полностью переобуться на новую версию? (И что вы в одной ветке переходите?)

У них разные подходы. В so_4 нет понятия mailbox-ов, у агентов и сообщений строковые имена. В so_5 нет понятия «владелец сообщения», нет строковых имен агентов и сообщений, есть mailbox-ы и более строгий контроль за действиями пользователя со стороны компилятора.

Переобутся на новую версию... Речь идет не о том, чтобы сам SObjectizer переделать из 4-й версии в 5-ю. А о том, что он задействован в довольно больших проектах, переписывать которые просто так смысла нет. Какие-то старые модули в этих проектах работают на so_4, какие-то новые на so_5.

А должны быть в нескольких классах в одном неймспейсе. Как по вашему я должен сделать свой вариант? Копипастом?

Ну и какая разница для вас будет в том, что so_5::disp::active_obj::create_disp — это статический метод класса active_obj в пространстве имен so_5::disp. А не свободная функция в пространстве имен so_5::disp::active_obj.

С классами даже хуже. Просто так using namespace не сделаешь.

Ну и вам не нужно свой вариант делать. Речь идет об использовании того, что уже сделано.

eao197 ★★★★★
() автор топика
Последнее исправление: eao197 (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.