На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
[!] Как относитесь к модерированию на этом форуме? Выскажите свое мнение здесь
Модераторы: Qraizer
Страницы: (14) [1] 2 3 ...  13 14 все  ( Перейти к последнему сообщению )  
> SObjectizer 5.3.0
    SObjectizer -- это реализация модели акторов для C++, позволяющая программировать на C++ с использованием работающих на разных нитях агентов, общающихся между собой посредством сообщений. SObjectizer существенно упрощает разработку событийно-ориентированных приложений, для параллельной и независимой обработки событий в которых требуется многопоточность и/или распределенность. SObjectizer использовался для создания как для мелких утилит, так и серьезных распределенных приложений, работающих под большой нагрузкой в режиме 24x7.

    Сегодня состоялся один из ключевых релизов, SObjectizer 5.3.0.

    SObjectizer является Opensource проектом.

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

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

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

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

    ExpandedWrap disabled
      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, где каждый агент работает на контексте своей собственной нити, вот так:

    ExpandedWrap disabled
      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 и его основах.

    ---

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

    Сама же тема предназначена для любых вопросов, пожеланий и уточнений, которые всячески приветствуются.
      bsivko, вы - автор?
        Скажем так - числюсь в команде разработчиков.

        Если вы что-либо тут спросите, то получите ответы непосредственно от авторов.
          Цитата bsivko @
          Традиционный пример “Hello, World” теперь может быть записан вот так:

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

          Цитата bsivko @
          А более интересный пример ping_pong, где каждый агент работает на контексте своей собственной нити, вот так:

          Это всё наверное дико круто, но хотелось бы, чтоб оно выглядело менее адово.
          Сообщение отредактировано: korvin -
            Цитата korvin @
            Это всё наверное дико круто, но хотелось бы, чтоб оно выглядело менее адово.

            Например. Но, я думаю, ты согласишься, что это всё не дотягивает до нормальных акторов без сопоставления с образцом.
            IMHO, libcppa более вменяемая в этом плане. bsivko, что скажете о конкуренте?
              Цитата MyNameIsIgor @
              Но, я думаю, ты согласишься, что это всё не дотягивает до нормальных акторов без сопоставления с образцом.

              Да в принципе можно и без сопоставления, если использовать тегированые (типом) значения и автоматически кастить их в нужный тип typecase'ом или типа того. А динамику можно эмулировать автоматическим же маршаллингом/демаршаллингом. Ну, просто мне кажется это будет попроще реализовать в C++, чем сопоставление с образцом, а результат практически тот же.
                Как-то так например.
                  Цитата korvin @
                  Это всё наверное дико круто, но хотелось бы, чтоб оно выглядело менее адово.

                  Так в C++ не получится. Если хочется писать так, нужно продолжать пользоваться Go :)

                  Можно писать и не злоупортребляя возможностями C++11. Например, в рамках "C с классами".
                    Цитата eao197 @
                    Так в C++ не получится

                    Т.е. boost.fiber не существует? :lool:
                      Цитата eao197 @
                      Так в C++ не получится.

                      Выше был пример с fiber, вполне читаемый код.

                      Добавлено
                      MyNameIsIgor, тебе за что уже RO прописали? =)
                        Цитата MyNameIsIgor @
                        Но, я думаю, ты согласишься, что это всё не дотягивает до нормальных акторов без сопоставления с образцом.
                        IMHO, libcppa более вменяемая в этом плане. bsivko, что скажете о конкуренте?

                        Понятие "нормальный актер" для C++ не определено. В Erlang-е да, одна, диктуемая языком форма актеров. В Scala своя, взятая из Akka. Хотя для той же JVM Akka не единственный такой инструмент.

                        Для C++ нет эталонной реализации модели актеров. И нужен ли в С++ паттерн-матчинг из Erlang-а или Scala -- тот еще вопрос. Пока же его нет, то какой смысл его имитировать абы как? В свое время в Boost-е пытались лямбды имитировать, как по мне, так был страх и ужас.

                        Что до сравнения с libcppa, то...

                        Если брать только аспект сопоставления с образцом, то в SObjectizer-е его вообще нет. У каждого сообщения должен быть свой уникальный тип, при этом данный тип должен быть наследником от message_t или signal_t. По typeid этого типа и производится связывание обработчика с типом сообщения. В этом плане SObjectizer не идет ни в какое сравнение с libcppa.

                        Если же вообще сравнивать SO и libcppa, то libcppa выглядит как максимально близкая калька с Erlang-а. Т.е. если хочется писать на C++ в стиле Erlang-а, то libcppa может и хорош. Но больше кажется, что для C++ это не очень подходящий стиль. Могу попробовать перечислить пару мест, которые сразу бросились в глаза.

                        Взять привязывание обработчика к типу сообщения. В libcppa это делается через явное указание всех элементов сообщения (или их части). Это хорошо в коротких демо-примерах. Но когда код сопровождается годами, то типы сообщений обязательно модифицируются. Что-то добавляется, что-то убирается. Подход libcppa приведет к геморрою по поиску и замене всех нужных обработчиков. Либо же придется все равно использовать тот же самый подход, что и в SO.

                        Все в libcppa завязано на лямбдах. Опять же, в простых примерах это выглядит привлекательно. Но вот как это будет в промышленном коде, который живет 10+ лет... У нас были агенты с десятками событий, были обработчики событий в десятки строк кода (причем нормально кода, структурированного) и т.д. и т.п. Когда обработчик сообщения -- это метод класса, то с этим вообще проблем нет, обычное ООП. В libcppa же нужно будет эти методы-обработчики обрамлять лямбда-функциями.

                        Очень много libcppa-специфики в коде агентов. Всякие become/unbecome и пр. Плюс тип агента, если используется наследование, нужно жестко прибивать -- event_based, sb_actor и пр. В SObjectizer агент -- это агент, контекст для него определяется диспетчером. Можно запустить агента на отдельной нити, можно с кем-нибудь еще -- он об этом особо и знать не будет. Опять же, состояния могут быть, а могут и не быть. Сегодня не нужны они агенту, он их не определяет. Через 3 года потребовались, добавили, и не нужно базовый тип для агента менять.

                        Опять же, притянутая из Erlang-а модель связывания и мониторинга, т.е. если порожденный актором дочерний актор падает, то можно словить сигнал об этом. В C++ толку от такого механизма чуть больше чем ноль. В Erlang-е этот подход работает, т.к. позволяет процессам вообще не заморачиваться на обработку многих ошибок: произошло деление на 0 из-за неправильного аргумента, ну и фиг с ним -- процесс упал, супервизор это увидел и перезапустил. В C++ нельзя допускать деления на 0, вся программа грохнется, а не один агент. Равно, как и нельзя допускать выхода за пределы массива. Или обращения по неверному указателю. В общем, в C++ процент ошибок, которые приложение может "пережить" и перезапустить затем проблемного агента, в разы (если не на порядки) меньше, чем в Erlang-е. От того этот механизм в libcppa выглядит прикольно, но реальной пользы от этого не будет. Нам в SObjectizer это вообще не понадобилось.

                        Общее же впечатление, как от Boost-а в свое время, когда Boost библиотеками пытался решить проблемы языка (тот же Boost.Lambda или Boost.Bind). Когда язык подкрутили, от этих вещей уже и проку нет. Вот так и libcppa -- пытается притянуть за уши то, чего в языке нет.

                        А вообще, libcppa мы не рассматриваем как конкурента. Слишком разные подходы у нас к модели актеров.
                        Пусть потенциальные пользователи сами смотрят и выбирают, что им ближе. Кому-то имитация Erlang-а на максимуме возможностей C++11. Кому-то более примитивный вариант, близкий к ООП. Ну и может кому-то будет важно, что SObjectizer поддерживает Windows "из коробки" :)

                        Добавлено
                        Цитата korvin @
                        Выше был пример с fiber, вполне читаемый код.


                        Пример с fiber не является аналогом приведенного bsivko примера ping_pong-а на SObjectizer-е.
                          Цитата korvin @
                          MyNameIsIgor, тебе за что уже RO прописали? =)

                          За пьяный дебош :D
                          Цитата eao197 @
                          Если брать только аспект сопоставления с образцом, то в SObjectizer-е его вообще нет

                          Да я заметил по if'у в ping-pong :D
                          Цитата eao197 @
                          У каждого сообщения должен быть свой уникальный тип, при этом данный тип должен быть наследником от message_t или signal_t

                          И чем обусловлено сие ограничение, при условии что
                          Цитата eao197 @
                          По typeid этого типа и производится связывание обработчика с типом сообщения

                          ?
                          Цитата eao197 @
                          В этом плане SObjectizer не идет ни в какое сравнение с libcppa

                          Да, SO тут как каменный топор по сравнению со стальным :yes:
                          Цитата eao197 @
                          Взять привязывание обработчика к типу сообщения. В libcppa это делается через явное указание всех элементов сообщения (или их части).

                          Простите, а у вас вот тут
                          ExpandedWrap disabled
                            .on_event( mbox, so_5::signal< msg_pong >

                          тип сообщения указывается как-то неявно? :wacko: Или вы про сопоставление с образцом? Да, там при привязке указывается образец. Но в случае SO всё равно будет этот код в обработчике в виде if'ов, да только сопоставление даёт структурированный код.
                          Цитата eao197 @
                          Это хорошо в коротких демо-примерах. Но когда код сопровождается годами, то типы сообщений обязательно модифицируются. Что-то добавляется, что-то убирается. Подход libcppa приведет к геморрою по поиску и замене всех нужных обработчиков. Либо же придется все равно использовать тот же самый подход, что и в SO.

                          А какая для поддержки кода половая разница как вы обрабатываете сообщения - сопоставлением с образцом или if'ами внутри обработчика? При изменении сообщения вам всё равно придётся заниматься "поиском и заменой", так что низачот.
                          Цитата eao197 @
                          Все в libcppa завязано на лямбдах.

                          На функторах, а не лямбдах.
                          Цитата eao197 @
                          Но вот как это будет в промышленном коде, который живет 10+ лет...

                          Будет жить 10+ лет...
                          Цитата eao197 @
                          Когда обработчик сообщения -- это метод класса, то с этим вообще проблем нет, обычное ООП. В libcppa же нужно будет эти методы-обработчики обрамлять лямбда-функциями.

                          bind же.
                          Цитата eao197 @
                          Очень много libcppa-специфики в коде агентов. Всякие become/unbecome и пр

                          Эммм... И что? Ну, переходят акторы в другие состояния... Вы предлагаете отказаться от этого, чтобы навелосипедить свою машину состояния и руками создать очередь сообщений? :blink:
                          Цитата eao197 @
                          Плюс тип агента, если используется наследование, нужно жестко прибивать -- event_based, sb_actor и пр. ... Опять же, состояния могут быть, а могут и не быть. Сегодня не нужны они агенту, он их не определяет. Через 3 года потребовались, добавили, и не нужно базовый тип для агента менять.

                          Ну, поменяли базовый тип, и что? Это трагедия?
                          Цитата eao197 @
                          Опять же, притянутая из Erlang-а модель связывания и мониторинга, т.е. если порожденный актором дочерний актор падает, то можно словить сигнал об этом. В C++ толку от такого механизма чуть больше чем ноль. (и далее по тексту)

                          Правильно ли я понимаю, что libcppa позволяет обработать исключение и падает приразыменовании nullptr, а SO падает в обоих случаях, и этот факт выдаётся за преимущество SO? Серьёзно?
                          Цитата eao197 @
                          Общее же впечатление, как от Boost-а в свое время, когда Boost библиотеками пытался решить проблемы языка (тот же Boost.Lambda или Boost.Bind). Когда язык подкрутили, от этих вещей уже и проку нет.

                          Да не пытались, а решали. И не убрали - bind в стандартной библиотеке. А некоторые преимущества в короткой записи boost.lambda можно увидеть в libcppa на примере guard'ов :) У вас их тоже нет, да.
                          Цитата eao197 @
                          Вот так и libcppa -- пытается притянуть за уши то, чего в языке нет

                          Мы тут пилим либу, которая притягивает в язык модель акторов, но обвиняем других :crazy:
                          Цитата eao197 @
                          А вообще, libcppa мы не рассматриваем как конкурента. Слишком разные подходы у нас к модели актеров.

                          Я не вижу разницы в подходах. Вижу разницу в продвинутости реализации - это да.
                          Цитата eao197 @
                          Ну и может кому-то будет важно, что SObjectizer поддерживает Windows "из коробки"

                          При чём здесь ОС? Речь идёт о поддержке компиляторов.
                          Цитата eao197 @
                          Пример с fiber не является аналогом приведенного bsivko примера ping_pong-а на SObjectizer-е.

                          Извините, за ручным созданием ящиков и каких-то диспетчеров активных объектов я просто не увидел разницы. В чём же она состоит?

                          Добавлено
                          D_KEY, подключайся ;)
                            Цитата MyNameIsIgor @
                            D_KEY, подключайся ;)

                            У вас итак хорошо получается, испорчу еще.
                              Цитата D_KEY @
                              У вас итак хорошо получается, испорчу еще.

                              Ну, вот, ты как всегда :yes-sad:
                                Цитата MyNameIsIgor
                                Да я заметил по if'у в ping-pong :D

                                Вы не то что-то заметили. if там используется не для определения типа сообщения, а для проверки количества оставшихся попыток для отсылки ping-а.
                                Соответственно, остальные ваши фантазии на эту тему являются плодом вашего бурного воображения. Или неспособности читать C++ный код.

                                Цитата MyNameIsIgor
                                И чем обусловлено сие ограничениех

                                Необходимостью хранения счетчика ссылок на экземпляр сообщения.

                                Цитата MyNameIsIgor
                                Будет жить 10+ лет...

                                Остается пожелать только, чтобы через 10+ лет сопровождением подобного кода пришлось заниматься именно вам.

                                Цитата MyNameIsIgor
                                Ну, поменяли базовый тип, и что? Это трагедия?

                                Нет. Просто не нужная работа.

                                Цитата MyNameIsIgor
                                Правильно ли я понимаю, что libcppa позволяет обработать исключение и падает приразыменовании nullptr, а SO падает в обоих случаях, и этот факт выдаётся за преимущество SO? Серьёзно?

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

                                Цитата MyNameIsIgor
                                Да не пытались, а решали. И не убрали - bind в стандартной библиотеке. А некоторые преимущества в короткой записи boost.lambda можно увидеть в libcppa на примере guard'ов :) У вас их тоже нет, да.

                                Без guard-ов жизни нет, совсем.

                                Цитата MyNameIsIgor
                                Мы тут пилим либу, которая притягивает в язык модель акторов, но обвиняем других :crazy:

                                Мы привносим в язык агентов без попытки создания нового поддиалекта языка.

                                Цитата MyNameIsIgor
                                Я не вижу разницы в подходах.

                                Как показали ваши высказывания выше, вы вообще мало чего видите.

                                Цитата MyNameIsIgor
                                Извините, за ручным созданием ящиков и каких-то диспетчеров активных объектов я просто не увидел разницы. В чём же она состоит?

                                Да у вас вообще со зрением что-то. Возьмите пример, указанный kovrin, перепишите его на Boost.Fiber и посмотрите, получится ли у вас менее адово. А потом попробуйте на тех же boost.fiber переписать пример, который bsivko привел на SObjectizer. И опять же посмотрите, будет ли это сопоставимо с кодом на Go.
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (14) [1] 2 3 ...  13 14 все


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0592 ]   [ 18 queries used ]   [ Generated: 28.03.24, 16:42 GMT ]