Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.142.197.198] |
|
Страницы: (14) [1] 2 3 ... 13 14 все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
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” теперь может быть записан вот так: 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 и его основах. --- Данное сообщение является анонсом самого факта существования проекта и его развития (ранее упоминание здесь было очень давно). Сама же тема предназначена для любых вопросов, пожеланий и уточнений, которые всячески приветствуются. |
Сообщ.
#2
,
|
|
|
bsivko, вы - автор?
|
Сообщ.
#3
,
|
|
|
Скажем так - числюсь в команде разработчиков.
Если вы что-либо тут спросите, то получите ответы непосредственно от авторов. |
Сообщ.
#4
,
|
|
|
Цитата bsivko @ Традиционный пример “Hello, World” теперь может быть записан вот так: Неплохо, осталось добавить монады, стрелки и категории эндофункторов. Цитата bsivko @ А более интересный пример ping_pong, где каждый агент работает на контексте своей собственной нити, вот так: Это всё наверное дико круто, но хотелось бы, чтоб оно выглядело менее адово. |
Сообщ.
#5
,
|
|
|
Сообщ.
#6
,
|
|
|
Цитата MyNameIsIgor @ Но, я думаю, ты согласишься, что это всё не дотягивает до нормальных акторов без сопоставления с образцом. Да в принципе можно и без сопоставления, если использовать тегированые (типом) значения и автоматически кастить их в нужный тип typecase'ом или типа того. А динамику можно эмулировать автоматическим же маршаллингом/демаршаллингом. Ну, просто мне кажется это будет попроще реализовать в C++, чем сопоставление с образцом, а результат практически тот же. |
Сообщ.
#8
,
|
|
|
Так в C++ не получится. Если хочется писать так, нужно продолжать пользоваться Go Можно писать и не злоупортребляя возможностями C++11. Например, в рамках "C с классами". |
Сообщ.
#9
,
|
|
|
Цитата eao197 @ Так в C++ не получится Т.е. boost.fiber не существует? |
Сообщ.
#10
,
|
|
|
Цитата eao197 @ Так в C++ не получится. Выше был пример с fiber, вполне читаемый код. Добавлено MyNameIsIgor, тебе за что уже RO прописали? =) |
Сообщ.
#11
,
|
|
|
Цитата 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-е. |
Сообщ.
#12
,
|
|
|
Цитата korvin @ MyNameIsIgor, тебе за что уже RO прописали? =) За Цитата eao197 @ Если брать только аспект сопоставления с образцом, то в SObjectizer-е его вообще нет Да я заметил по if'у в ping-pong Цитата eao197 @ У каждого сообщения должен быть свой уникальный тип, при этом данный тип должен быть наследником от message_t или signal_t И чем обусловлено сие ограничение, при условии что Цитата eao197 @ По typeid этого типа и производится связывание обработчика с типом сообщения ? Цитата eao197 @ В этом плане SObjectizer не идет ни в какое сравнение с libcppa Да, SO тут как каменный топор по сравнению со стальным Цитата eao197 @ Взять привязывание обработчика к типу сообщения. В libcppa это делается через явное указание всех элементов сообщения (или их части). Простите, а у вас вот тут .on_event( mbox, so_5::signal< msg_pong > тип сообщения указывается как-то неявно? Или вы про сопоставление с образцом? Да, там при привязке указывается образец. Но в случае SO всё равно будет этот код в обработчике в виде if'ов, да только сопоставление даёт структурированный код. Цитата eao197 @ Это хорошо в коротких демо-примерах. Но когда код сопровождается годами, то типы сообщений обязательно модифицируются. Что-то добавляется, что-то убирается. Подход libcppa приведет к геморрою по поиску и замене всех нужных обработчиков. Либо же придется все равно использовать тот же самый подход, что и в SO. А какая для поддержки кода половая разница как вы обрабатываете сообщения - сопоставлением с образцом или if'ами внутри обработчика? При изменении сообщения вам всё равно придётся заниматься "поиском и заменой", так что низачот. Цитата eao197 @ Все в libcppa завязано на лямбдах. На функторах, а не лямбдах. Цитата eao197 @ Но вот как это будет в промышленном коде, который живет 10+ лет... Будет жить 10+ лет... Цитата eao197 @ Когда обработчик сообщения -- это метод класса, то с этим вообще проблем нет, обычное ООП. В libcppa же нужно будет эти методы-обработчики обрамлять лямбда-функциями. bind же. Цитата eao197 @ Очень много libcppa-специфики в коде агентов. Всякие become/unbecome и пр Эммм... И что? Ну, переходят акторы в другие состояния... Вы предлагаете отказаться от этого, чтобы навелосипедить свою машину состояния и руками создать очередь сообщений? Цитата 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 -- пытается притянуть за уши то, чего в языке нет Мы тут пилим либу, которая притягивает в язык модель акторов, но обвиняем других Цитата eao197 @ А вообще, libcppa мы не рассматриваем как конкурента. Слишком разные подходы у нас к модели актеров. Я не вижу разницы в подходах. Вижу разницу в продвинутости реализации - это да. Цитата eao197 @ Ну и может кому-то будет важно, что SObjectizer поддерживает Windows "из коробки" При чём здесь ОС? Речь идёт о поддержке компиляторов. Цитата eao197 @ Пример с fiber не является аналогом приведенного bsivko примера ping_pong-а на SObjectizer-е. Извините, за ручным созданием ящиков и каких-то диспетчеров активных объектов я просто не увидел разницы. В чём же она состоит? Добавлено D_KEY, подключайся |
Сообщ.
#13
,
|
|
|
Цитата MyNameIsIgor @ D_KEY, подключайся У вас итак хорошо получается, испорчу еще. |
Сообщ.
#14
,
|
|
|
Цитата D_KEY @ У вас итак хорошо получается, испорчу еще. Ну, вот, ты как всегда |
Сообщ.
#15
,
|
|
|
Цитата MyNameIsIgor Да я заметил по if'у в ping-pong Вы не то что-то заметили. if там используется не для определения типа сообщения, а для проверки количества оставшихся попыток для отсылки ping-а. Соответственно, остальные ваши фантазии на эту тему являются плодом вашего бурного воображения. Или неспособности читать C++ный код. Цитата MyNameIsIgor И чем обусловлено сие ограничениех Необходимостью хранения счетчика ссылок на экземпляр сообщения. Цитата MyNameIsIgor Будет жить 10+ лет... Остается пожелать только, чтобы через 10+ лет сопровождением подобного кода пришлось заниматься именно вам. Цитата MyNameIsIgor Ну, поменяли базовый тип, и что? Это трагедия? Нет. Просто не нужная работа. Цитата MyNameIsIgor Правильно ли я понимаю, что libcppa позволяет обработать исключение и падает приразыменовании nullptr, а SO падает в обоих случаях, и этот факт выдаётся за преимущество SO? Серьёзно? Не правильно. Хотя вряд ли вы вообще что-то понимаете в C++ и последствиях таких ошибок, как деление на ноль, выход за пределы массива с перезаписью чужой памяти, обращение по неверному указателю и т.д. Цитата MyNameIsIgor Да не пытались, а решали. И не убрали - bind в стандартной библиотеке. А некоторые преимущества в короткой записи boost.lambda можно увидеть в libcppa на примере guard'ов У вас их тоже нет, да. Без guard-ов жизни нет, совсем. Цитата MyNameIsIgor Мы тут пилим либу, которая притягивает в язык модель акторов, но обвиняем других Мы привносим в язык агентов без попытки создания нового поддиалекта языка. Цитата MyNameIsIgor Я не вижу разницы в подходах. Как показали ваши высказывания выше, вы вообще мало чего видите. Цитата MyNameIsIgor Извините, за ручным созданием ящиков и каких-то диспетчеров активных объектов я просто не увидел разницы. В чём же она состоит? Да у вас вообще со зрением что-то. Возьмите пример, указанный kovrin, перепишите его на Boost.Fiber и посмотрите, получится ли у вас менее адово. А потом попробуйте на тех же boost.fiber переписать пример, который bsivko привел на SObjectizer. И опять же посмотрите, будет ли это сопоставимо с кодом на Go. |