— однопоточная реализация SObjectizer на базе Asio, которая при этом является еще и thread-safe. Предназначена для случаев, например, когда нужно иметь свободный основной поток для GUI и отдельный рабочий поток, на котором будет совместно работать и SObjectizer, и Asio. И чтобы из главного потока можно было управлять SObjectizer-ом (создавать/удалять кооперации, отсылать сообщения, создавать mchain-ы и т.д.);
— диспетчер asio_thread_pool. Этот диспетчер создает пул рабочих потоков, на каждом из которых запускает io_service::run(). При этом диспетчеризация событий для агентов, которые привязаны к данному диспетчеру происходит через asio::post. Это позволяет привязанным к asio_thread_pool диспетчеру агентам выполнять IO-операции там же, где работает сам Asio-шный io_service.
Попутно мы обновили SO-5, но там вообще ничего не добавилось. Просто устранены предупреждения, которые стал выдавать clang-5.0.0. Что должно помочь тем, кто у себя компилирует SObjectizer clang-ом с высокими уровнями предупреждений.
---
Попутно открывается возможность начать работу над следующей версией SO-5. Точного списка фич для версии 5.5.20 пока нет, будет выбрано несколько пунктов из этого wish-list-а. Если у кого-то есть пожелания о том, что хотелось бы видеть в SObjectizer-е, можно высказать их, мы постараемся их учесть.
На этот раз добавили в SO-5 проверку наличия подписок для агента. Оказалось, что бывают сценарии, где это востребовано. Заодно пофиксили формат некоторых методов so_drop_subscription, которые не менялись очень давно и не поддерживали новый формат event-handler-ов. В общем, изменения небольшие, но полезные.
В следующем году мы планируем заняться версией 5.6, в которой будет нарушена совместимость с текущей веткой 5.5. Сделано это будет как для того, чтобы устранить выявленные за время эксплуатации SO-5 косяки, так и для того, чтобы сделать вещи, которые сейчас не представляется возможным внедрить в 5.5 без нарушения совместимости.
Первые идеи по поводу SO-5.6 можно посмотреть здесь. Соответственно, конструктивные соображения/замечания/предложения приветствуются и будут обязательно приняты к сведению. А может быть даже и реализованы
Мы рады сообщить о выходе обновленных версий SObjectizer и сопутствующего проекта so_5_extra.
SObjectizer обновился до версии 5.5.20. Изменений в нем немного. Пожалуй, самое важное -- это обновленная и улучшенная поддержка CMake. Полный список изменений можно увидеть здесь.
Уже пару месяцев SObjectizer доступен через систему управления зависимостями vcpkg. Так что сейчас последнюю версию SO-5 можно установить себе посредством команды vcpkg install sobjectizer.
so_5_extra обновился до версии 1.0.3, в которой был добавлен еще один тип mbox-а: retained_msg mbox.
Мы обновили SObjectizer до версии 5.5.21, а so_5_extra до версии 1.0.4.
Самое главное в этом релизе -- это появление в so_5_extra такой штуки, как асинхронные операции или просто async_op. Асинхронные операции значительно упрощают реализацию эпизодических однократных взаимодействий между агентами. Происходит это из-за того, что асинхронная операция берет на себя задачи по подписке на нужные сообщения при начале асинхронной операции и по удалению подписок после того, как результат операции будет получен. А так же async_op берет на себя задачи работы с отложенными сообщениями, если для операции существует лимит на время выполнения.
Ну, например, пусть мы делаем агента распределяющего обработку запросов по нескольким обработчикам запросов. Этот агент получает сообщение request_data, определяет mbox, в который нужно переслать сообщение, а затем дождаться получение из этого mbox-а либо сообщения request_successed, либо сообщения request_failed. Так же должен учитываться тайм-аут на обработку запроса. Посредством асинхронных операций это может быть реализовано вот так:
Для того, чтобы сделать async_op в so_5_extra пришлось добавить в SO-5.5 такую штуку, как deadletter handler. Можно зарегистрировать deadletter handler для пары (message_type, mbox) и deadletter handler будет вызван, если у агента в его текущем состоянии нет обработчика для такой пары и типа сообщения и почтового ящика. Что позволяет делать обработчики сообщений "по умолчанию".
Взять дистрибутив новой версии SObjectizer-а можно из раздела Files на SourceForge. Документация по изменениям в версии 5.5.21 доступна здесь. Так же можно воспользоваться зеркалом на github. Пользователи vcpkg могут установить последнюю версию SObjectizer через vcpkg install sobjectizer.
Дистрибутив новой версии so_5_extra можно взять из раздела Files на SourceForge. Документация по изменениям в версии 1.0.4 доступна здесь.
Если кому-то интересно наблюдать за развитием SObjectizer-а и/или хочется повлиять на то, что и как добавляется в SObjectizer, то вот подходящий случай:
Мы выпустили очередную версию: SObjectizer-5.5.22.
Самое важное в новой версии -- это возможность назначить фильтр для механизма трассировки процесса доставки сообщений (message_delivery_tracing или msg_tracing, если более коротко). Если раньше при включении msg_tracing-а SObjectizer выдавал информацию вообще обо всем, что касается доставки сообщений, что делало использование msg_tracing неудобным в больших приложениях, то теперь посредством msg_tracing-фильтров можно оставить только то, что вам интересно. Например, только информацию о сообщениях определенного типа. Или только информацию, относящуюся к конкретной рабочей нити. И т.д.
Возможность пока что экспериментальная, но уже показавшая себя с хорошей стороны. Так что если у кого-то будут соображения о том, как сделать ее еще лучше, то будет интересно их послушать.
Еще в 5.5.22 добавлена возможность использовать свободные функции в качестве обработчиков сообщений в функциях для работы с CSP-шными каналами so_5::receive и so_5::select. И изменено поведение agent_t::so_current_state() -- теперь если этот метод вызывается внутри on_enter/on_exit обработчиков, то so_current_state() возвращает ссылку на то состояние, обработчик on_enter/on_exit которого сейчас активен.
Так же мы обновили надстройку над SObjectizer-ом, библиотеку so_5_extra. so_5_extra обновилась до версии 1.1.0. Но нового в нее ничего не добавилось, только произошел переход на Asio-1.12 и SO-5.5.22. Для этого пришлось перелопатить часть библиотеки и выпустить версию 1.1.0 вместо 1.0.5. Кстати говоря, если вы использовали so_5_extra-1.0.4, то для перехода на SO-5.5.22 вам придется перейти и на so_5_extra-1.1.0, т.к. в SO-5.5.22 сломалась совместимость в той части, где идет работа с кастомными mbox-ами.
so_5_extra живет на SourceForge, взять ее можно оттуда же. Правда, распространяется so_5_extra уже под двойной лицензией.
=====
Отдельно хотелось бы отметить вот какой момент. Мы свой список хотелок для SObjectizer-а исчерпали где-то в районе версии 5.5.19 (т.е. чуть меньше года назад). С тех пор в SO-5.5 добавляются только те фичи, которые кому-нибудь понадобились. Либо нам самим, либо кому-то из пользователей.
С релизом версии 5.5.22 на этом стоит заострить особое внимание: в ветку SObjectizer-5.5 новые фичи теперь попадают только если a) они кому-то нужны и b) нас об этом просят.
Т.е. если вы хотите что-то увидеть в SObjectizer, но нам вы об этом не рассказали и мы об этом не узнали, то в ветке 5.5 вы этого точно не увидите.
=====
Было бы здорово услышать мнение тех, кто смотрел в сторону SObjectizer-а, но не выбрал его в качестве инструмента. Что остановило? Что не понравилось? Что вы не увидели в SObjectizer? Или, напротив, что такого страшного увидели?
Конструктивная обратная связь такого рода поможет нам сделать SObjectizer лучше.
Мы подготовили статью, в которой постарались рассказать (и показать на картинках) про основные сущности, которые есть в SObjectizer, а так же про взаимосвязи и взаимодействие этих сущностей: Давайте заглянем SObjectizer-у под капот.
На этот раз мы знакомим читателя с программированием без агентов/акторов, но с использованием CSP-шных каналов, которые в SObjectizer-е называются mchain-ы.
Если не будет дополнительных "вбрасываний" от читателей, то следующая запланированная статья расскажет о том, как можно построить транспорт на базе SObjectizer-овских mbox-ов и MQTT-брокера.
Кто не любит Хабр, тот может сказать свое "фи" оставить свой комментарий здесь.
Здравствуйте, nen777w, Вы писали:
N>Может офтопик, но почему вы не добавите вашу библиотеку к boost ?
Наверное, потому, что мы не видим хорошего ответа на вопрос "Зачем SObjectizer в Boost?"
Если попробовать ответить на вопрос более развернуто, то можно выделить два момента (не считая моментов поменьше, которые не хочется выносить на публику):
1. Библиотеки/фреймворки делятся на две категории. Первая категория -- это общеупотребительные библиотеки, т.е. библиотеки, которые решают хорошо знакомые большинству разработчиков задачи. Например, работа с регулярными выражениями, с файловой системой, с сетью, датами, строками и пр. Вторая категория -- это специализированные библиотеки, которые решают специфические задачи. Скажем, библиотека для парсинга какого-то специфического протокола (вроде FIX или ISO 8583) или каких-то специфических форматов данных (например GSM 03.40). Или какая-нибудь реализация CORBA-брокера.
Конгломераты библиотек, вроде Boost-а, как нам думается, предназначены прежде всего для общеупотребительных библиотек. Помещать в Boost специализированные библиотеки, которые нужны узкому кругу программистов, наверное, не есть хорошая идея. А так как мы рассматриваем SObjectizer именно как специализированную библиотеку, то не считаем правильным запихивать SO-5 под одну крышу с такими общеупотребительными библиотеками, как Boost.Algorithm, Boost.Container, Boost.Hana и пр.
2. Роль Boost-а в C++ сообществе в настоящее время. Если смотреть на Boost как на полигон, на котором испытываются новые вещи, которые со временем попадут в стандарт, то добавление SObjectizer-а в Boost не имеет смысла, т.к. нам не кажется хорошей идеей включение инструмента вроде SObjectizer в стандартную библиотеку C++.
Если смотреть на Boost просто как на коллекцию библиотек, которые проверены временем и, якобы, должны иметь высокое качество, то тут вообще сложный момент. По крайней мере у одного члена нашей команды есть мнение, что в таком качестве Boost сейчас не способствует развитию C++ной экосистемы, а препятствует оному. Т.е. библиотека, попадая в Boost, оказывается в лучшем положении, чем библиотеки, не входящие в Boost. Вот, скажем, человек ищет себе инструмент для unit-тестирование, начинает поиск с Boost-а и останавливается на Boost.Test, при этом он может даже не узнать, что есть не менее интересные альтернативы в виде Catch2 или doctest.
Соответственно, есть мнение в нашей команде, что существование Boost-а в его нынешнем виде пагубно сказывается на конкуренции между C++ными библиотеками. А раз так, то было бы непоследовательно с одной стороны говорить о том, что Boost в его нынешнем виде, скорее всего, изжил (изживает) себя. А с другой стороны -- пропихивать в Boost свою разработку.
Ну и встречный вопрос: а вам реально нужен SObjectizer в Boost-е? Если да, то зачем и почему он вам нужен именно в Boost-е?
Недавно в Питере прошел очередной митап сообщества St.Peterburg C++ User Group на котором наш коллега выступил с докладом "Акторы в C++: взгляд старого практикующего актородела". В докладе речь шла про Модель Акторов и ее применимость в C++ вообще, а так же о SObjectizer-е в частности.
Для тех, кто не хочет читать рунглиш, краткое изложение:
добавить в SO-5.5 какие-то средства для адаптивной балансировки нагрузки (т.е. как-то добавить в SO-5.5 кроме "push"-модели еще и "pull"-модель);
возможно, при этом еще и получится заиметь простую интеграцию mchain-ов и агентов. Т.е. сообщение отсылается в mchain, а связанный с этим mchain-ом агент получает сообщение обычным образом;
гарантированная отмена таймеров. Ибо сейчас если при отмене таймера сообщение уже стоит в очереди агента, то до агента сообщение все-таки дойдет;
возможно при реализации отмены таймеров получится еще и заиметь механизм отмены/отзыва отосланных ранее сообщений. Или сообщений, надобность обработки которых меняется со временем;
функционал, аналогичный ReceiveTimeout из Akka. Т.е. если какой-то актор сидит без дела некоторое время, то ему прилетает специальное уведомление;
какой-то инструментарий для unit-тестирования агентов.
Можно высказываться как по поводу того, что было обозначено нами (вроде нужно/не нужно). Так и предложить то, чего лично вам не хватает. Если не удобно оставлять комментарии на SF.net, то это можно сделать здесь.
Еще мы хотим подготовить и опубликовать на Хабре очередную статью. Пока предполагаемая тема -- это разбор примера intercom_statechart, в котором иерархические конечные автоматы используются на полную катушку. Но если кому-то интересно что-то другое, то обозначайте. Постараемся раскрыть интересную вам тему. Либо в ближайшей статье, либо в одной из последующих.
Re: Статья про иерархические конечные автоматы и SO-5.5
Мы подготовили очередную статью с рассказом про возможности SObjectizer.
Эта статья может быть интересна не только тем, кто интересуется SObjectizer-ом, но и тем, кто раньше не сталкивался с иерархическими конечными автоматами. Первая часть статьи рассказывает именно про ИКА и их продвинутые возможности.
Вот здесь изложено что-то вроде плана работ над SObjectizer-5 на 2018 и 2019-й.
У всех заинтересованных или просто сочувствующих есть возможность повлиять на то, что, когда и как в SO-5 попадет. Оставить свои пожелания о том, что вы хотите видеть или чего не хотите видеть в SObjectizer-е, можно либо в комментариях в блоге, либо прямо здесь.
Здравствуйте, niXman, Вы писали:
X>скажите, а дока соответствует последим изменениям?
Та, что в Wiki проекта -- да. То, что на SlideShare, может соответствовать более старым версиям, т.к. с некоторых пор там убрали возможность обновлять ранее опубликованные PDF-ки. Но даже и на SlideShare вполне себе актуальная информация, т.к. в рамках ветки 5.5 каких-то серьезных ломающих изменений мы не допускали.
X>или чтоб заюзать последнюю версию нужно читать доку с каким-то оговорками? или другую доку?
Никаких оговорок. Если найдете какое-то несоответствие -- окрывайте issue, это наш косяк и мы его будем исправлять.
