Сегодня мы официально выкатили очередную версию SObjectizer-а -- 5.5.19. В этой версии реализованы две большие фичи, которые казались немыслимыми еще совсем недавно.
Во-первых, добавлена возможность запускать SObjectizer в однопоточном режиме. Т.е. теперь можно написать приложение на акторах так, что все акторы и вся вспомогательная кухня самого SObjectizer-а будут работать на одной единственной рабочей нити. Это может пригодиться при написании простых приложений, в которых наличие акторов может быть выгодно (для упрощения логики), а вот создание нескольких рабочих потоков -- это уже оверкилл. Например, если маленькая программка должна собирать какую-то информацию и время от времени публиковать ее через MQTT. Или, скажем, при написании своей хитрой версии traceroute. Вот маленькая демонстрация того, к чему все это может прийти в пределе: тривиальный http-сервер для асинхронной обработки запросов на базе SObjectizer и restinio.
Во-вторых, добавлена возможность отсылки мутабельных сообщений. Поскольку ноги у SO-5 растут из модели Publish/Subscribe, в которой взаимодействие идет в режиме 1:N, все сообщения в SO-5 изначально были иммутабельными. В большинстве случаев это упрощало жизнь, но мешало в тех ситуациях, когда нужно было, например, построить обработку данных в режиме конвейера: один агент модифицировал данные и передавал их следующему в конвейере, при этом взаимодействие в конвейере всегда идет в режиме 1:1. В итоге в версии 5.5.19 добавлена поддержка мутабельных сообщений с обеспечением гарантии того, что мутабельное сообщение будет доставлено не более чем одному получателю. Подробнее все это показано в новой презентации из серии "Dive into SObjectizer-5.5". Кстати говоря, данная фича появилась после общения в кулуарах на C++ Russua 2017.
Для будущей версии 5.5.20 у нас есть несколько своих идей, но в этом плане мы полностью открыты и готовы выслушать любые замечания и предложения. Так что, если кто-нибудь расскажет, что он хотел бы видеть в SObjectizer или, напротив, чего бы не хотел, то мы постараемся учесть это в своей работе. Опыт реализации таких фич, как отказ от дополнительного пространства имен so_5::rt, приоритеты агентов, иерархические конечные автоматы и мутабельные сообщения показывает, что это более чем возможно.
ЗЫ. Старую тему с анонсами SO-5 решил не поднимать, т.к. было это уже слишком давно. Для, кто не в курсе, что такое SObjectizer -- это один из немногих живых и развивающихся OpenSource кросс-платформенных фреймворков для C++, которые дают разработчику возможность использовать Actor Model (в случае с SO-5 сюда добавляются еще и Pub/Sub, и CSP).
Здравствуйте, so5team, Вы писали:
S>Во-первых, добавлена возможность запускать SObjectizer в однопоточном режиме. Т.е. теперь можно написать приложение на акторах так, что все акторы и вся вспомогательная кухня самого SObjectizer-а будут работать на одной единственной рабочей нити. Это может пригодиться при написании простых приложений, в которых наличие акторов может быть выгодно (для упрощения логики), а вот создание нескольких рабочих потоков -- это уже оверкилл. Например, если маленькая программка должна собирать какую-то информацию и время от времени публиковать ее через MQTT. Или, скажем, при написании своей хитрой версии traceroute. Вот маленькая демонстрация того, к чему все это может прийти в пределе: тривиальный http-сервер для асинхронной обработки запросов на базе SObjectizer и restinio.
У меня практический вопрос. В одной программе мне нужен был простенький http server, однопоточный тоже подойдёт. Я взял готовый как раз из boost::asio. Он не такой маленький, как в твоём примере, но я его и не писал — взял готовый.
Раз вы приводите такой пример, также используете boost::asio, то было бы неплохо сравнить две реализации. Чем ваш лучше? Лично мне было бы интересно.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, so5team, Вы писали:
N>У меня практический вопрос. В одной программе мне нужен был простенький http server, однопоточный тоже подойдёт. Я взял готовый как раз из boost::asio. Он не такой маленький, как в твоём примере, но я его и не писал — взял готовый. N>Раз вы приводите такой пример, также используете boost::asio, то было бы неплохо сравнить две реализации. Чем ваш лучше? Лично мне было бы интересно.
Все зависит от критерия, которым сравнивать.
Если ситуация такова, что заранее определена логика того, что нужно отвечать на конкретный запрос, то разница между:
1. взять набор кода из примера asio и изменить в нем обработчик (суть одну функцию);
2. взять набор кода sobjectizer+restinio и изменить в нем тоже только обработчик;
невелика, и зависит не от функциональности sobjectizer+restinio, а скорее от удобства сборки, размером бинарников, скорости компиляции.
Хотя сравнивая уже даже только эти примеры, между ними есть разница. В asio примере запрос обрабатывается синхронно, т.е. получив запрос идет обращение к обработчику, после чего ответ пишется в сокет. Из примера:
request_handler_.handle_request(request_, reply_); // Вызов обработчика.
do_write(); // Ожидается, что ответ уже готов.
А теперь представим, что ответ нельзя получить сразу, например, нужно обратиться к какому-то асинхронному API, и вот тут возможны два основных варианта:
1. обработчик залипает на некоторое время, пока не будут готовы данные для ответа;
2. обработчик должен уметь работать асинхронно: получив запрос, взять его в обработку, и освободить нить исполнения для обработки других соединений и их обработчиков, а когда данные для ответа будут получены надо иметь возможность собрать и отправить ответ.
C примером на asio легко применить первый вариант, а вот второй уже надо будет хорошенько переделывать логику работы класса connection и обработчика. В примере на sobjectizer+restinio второй вариант сразу в наличии и есть. В примере просто продемонстрирован вход к SObjectizer через http, а SObjectizer это асинхронность в полный рост, но это в примере полностью, конечно, не раскрыто.
Еще можно посмотреть на синтаксические отличия. В RESTinio удобнее работать с заголовками и удобнее строить ответ. Еще вопрос на сколько проверенный http-парсер в asioпримере, в RESTinio используется nodejs/http-parser.
Здравствуйте, so5team, Вы писали:
S>Сегодня мы официально выкатили очередную версию SObjectizer-а -- 5.5.19. В этой версии реализованы две большие фичи, которые казались немыслимыми еще совсем недавно.
Хотелось бы сделать одно предложение по документации. С ней, в принципе, всё прекрасно, да и ты на вопросы отвечаешь, но (для корпоративного мира) не хватает такой мелочи как "успешные истории внедрения". Реально, сильно помогло бы ответить на довольно формальный вопрос "а почему нужно их взять?"
Здравствуйте, kaa.python, Вы писали:
KP>Хотелось бы сделать одно предложение по документации. С ней, в принципе, всё прекрасно, да и ты на вопросы отвечаешь, но (для корпоративного мира) не хватает такой мелочи как "успешные истории внедрения". Реально, сильно помогло бы ответить на довольно формальный вопрос "а почему нужно их взять?"
Нужно будет пообщаться с нашими прошлыми работодателями. Есть некоторые сомнения в том, что там захотят открывать подробности реализации использующих SObjectizer проектов. Если получится, сделаем что-то вроде подборки success stories.
Здравствуйте, so5team, Вы писали:
S>C примером на asio легко применить первый вариант, а вот второй уже надо будет хорошенько переделывать логику работы класса connection и обработчика. В примере на sobjectizer+restinio второй вариант сразу в наличии и есть. В примере просто продемонстрирован вход к SObjectizer через http, а SObjectizer это асинхронность в полный рост, но это в примере полностью, конечно, не раскрыто.
S>Еще можно посмотреть на синтаксические отличия. В RESTinio удобнее работать с заголовками и удобнее строить ответ. Еще вопрос на сколько проверенный http-парсер в asioпримере, в RESTinio используется S>nodejs/http-parser.
Это уже интересно. Но, конечно, полноценный пример пощупать руками хотелось бы, чтобы делать выводы.
В boost::asio парсер используется самописный, он часть примера.
Здравствуйте, so5team, Вы писали:
S>Во-первых, добавлена возможность запускать SObjectizer в однопоточном режиме. Т.е. теперь можно написать приложение на акторах так, что все акторы и вся вспомогательная кухня самого SObjectizer-а будут работать на одной единственной рабочей нити.
т.е. SObjectizer не создает вообще ни одного дополнительного потока?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
S>>Во-первых, добавлена возможность запускать SObjectizer в однопоточном режиме. Т.е. теперь можно написать приложение на акторах так, что все акторы и вся вспомогательная кухня самого SObjectizer-а будут работать на одной единственной рабочей нити.
X>т.е. SObjectizer не создает вообще ни одного дополнительного потока?
Да, может все делать только на том потоке, на котором его запустили. Здесь подробнее на эту тему.
Здравствуйте, so5team, Вы писали:
S>Сегодня мы официально выкатили очередную версию SObjectizer-а -- 5.5.19. В этой версии реализованы две большие фичи, которые казались немыслимыми еще совсем недавно.
А когда появиться so_5_extra(интересует именно интеграция с asio)?
Здравствуйте, YuriV, Вы писали:
S>>Сегодня мы официально выкатили очередную версию SObjectizer-а -- 5.5.19. В этой версии реализованы две большие фичи, которые казались немыслимыми еще совсем недавно.
YV>А когда появиться so_5_extra(интересует именно интеграция с asio)?
Ну или если хотелось бы чего-то, что уже есть, но сделанного по-другому, то нам бы так же было бы интересно выслушать стороннее мнение. Есть далеко не нулевые шансы, что мы прислушаемся
Мы выпустили первую версию своего нового проекта поверх SObjectizer -- so_5_extra версии 1.0.0.
В этой версии в so_5_extra доступны:
so_5::extra::env_infrastructures::asio::simple_not_mtsafe -- реализация однопоточной инфраструктуры SObjectizer-а на базе Asio. Т.е. с использованием этой инфраструктуры и Asio, и SObjectizer смогут работать на одной и той же рабочей нити; so_5::extra::mboxes::round_robin -- специальный mbox, который доставляет сообщения поочередно каждому из N агентов, подписанных на это сообщение; so_5::extra::shutdowner -- небольшой инструмент для упрощения операции завершения работы в больших приложениях.</li>
Исходники можно взять либо из репозитория, либо загрузить из соответствующего раздела.
Документацию по проекту можно найти в Wiki. Если из документации чего-то не понятно или что-то в ней не описано, то не сочтите за труд, дайте нам знать. Улучшим, расширим и углубим
Проект header-only. Если захочется собрать тесты и примеры самостоятельно, то придется воспользоваться Ruby и Mxx_ru. Зависимости так же подтягиваются через MxxRu::externals. Но в секции Files есть архивы с именами вида so_5_extra-1.0.0-full.tar.xz, в которых уже все зависимости присутствуют. Поэтому можно брать *-full.tar.xz архив, распаковывать, прописывать в INCLUDE путь к so_5_extra-1.0.0/dev и пробовать.
Работоспособность проверялась под Linux-ом (gcc 5.4 и 7.1, clang 3.7 и 4.8) и Windows (gcc 5.2-7.1, VC++ 14.0 и 15.0). На всякий случай выставлять -Werror при работе с so_5_extra не советуем, т.к. и gcc, и clang очень сильно ругаются на потроха Asio.
В планах у нас добавление еще нескольких фич в so_5_extra. Следующие версии будут выходить по мере добавления новых фич. В том числе в планах и simple_mtsafe-инфраструктура для Asio, но приоритет у этой задачи не самый высокий. Если кому-то нужна thread-safe реализация Asio-инфраструктуры для SO-5, то дайте знать. Постараемся повысить приоритет.
Обращаем внимание, что so_5_extra распространяется под двойной лицензией: GNU Affero GPL для OpenSource применения, и коммерческая лицензия для использования в закрытых проектах. Если кому-то интересна коммерческая лицензия, то пишите на info at stiffstream dot com, там цена вопроса порядка $40 за одного разработчика в год.
Попутно мы сделали SObjectizer-5.5.19.2, в который вошло несколько фич, необходимых для реализации so_5_extra. Дистрибутивы SObjectizer лежат там же, где и обычно.
Извиняемся за ссылку на Хабр, но мы сделали большую статью, в которой подробно рассматривается намного более сложный пример, чем абстрактные и бесполезные на практике ping-pong-и (коими принято меряться в разговорах про акторные фреймворки): Имитируем управление устройствами с помощью акторов
Re[2]: Свежая статья (разбор примера machine_control)
Здравствуйте, so5team, Вы писали:
S>Извиняемся за ссылку на Хабр, но мы сделали большую статью, в которой подробно рассматривается намного более сложный пример, чем абстрактные и бесполезные на практике ping-pong-и (коими принято меряться в разговорах про акторные фреймворки): Имитируем управление устройствами с помощью акторов
Linux.
Созрели до использования в продакшене, смотрели на CAF, но как-то займно слишком у ребят всё.
Есть актор(ы), который висит на asio сокете, при успешном accept — создаётся дочерний актор и в него уходит свежий сокет из которого потом происходит чтение/запись.
При ошибке сокета актор сам себя удаляет из кооперации.
Дочерних актров планируется порядка сотен.
Работать, наврено, будут на thread_pool с размером 8-16.
Коммуникация не очень активная. В основном будут записи в сокет, которые инициирует сервер.
Так вот вопрос.
Есть ликакие-то подводные камни, на которые следует обратить внимание при совместной работе SO и boost::asio?
Re[3]: Свежая статья (разбор примера machine_control)
Здравствуйте, dr. Acula, Вы писали:
DA>Так вот вопрос. DA>Есть ликакие-то подводные камни, на которые следует обратить внимание при совместной работе SO и boost::asio?
Главный камень -- это то, что для Asio нужен свой набор рабочих потоков, на которых будет крутиться asio::io_service::run(), а SO нужен свой набор рабочих потоков, на которых будут работать SO-шные агенты. И просто так эти наборы рабочих потоков не подружить.
У нас сейчас есть реализация однопоточного SO, в которой Asio и SO работают на одном потоке (фактически, там работает asio::io_service::run(), а SO пользуется средствами Asio для диспетчеризации своих событий). Но она именно что однопоточная, реализации для совместной работы Asio и SO на thread_pool-е пока еще нет.
Но даже если Asio и SO используют один и тот же рабочий контекст, все равно идея об вызове Asio-шных accept/read/write из агентов не выглядит разумной. Дело в том, что если read/write синхронные и блокирующие, то агент просто заблокирует рабочую нить и это не позволит другим агентам использовать эту рабочую нить. Можно попробовать использовать async_read/async_write, но тогда нужно будет обвешивать агентов stand-ами, дабы не получилось, что Asio дергает коллбэк для async-операции на одной рабочей нити, а SO дергает событие этого же агента на другой.
А почему вы решили, что вам здесь нужны акторы? По вашему описанию создается ощущение, что вам достаточно родных средств самого Asio. Так, у вас будет какой-то объект, реагирующий на успешные accept-ы. Он создает другие объекты, которые получают готовый сокет и выполняют асинхронные I/O операции посредством вызова async_read/async_write. Что-то вроде:
Есть ощущение, что вот такого использования Asio вам может хватить и без привлечения какого-либо акторного фреймворка.
Если же все-таки нужны кроме обработчиков I/O операций еще и акторы, то на данный момент единственный способ сделать такое -- это иметь отдельные объекты для I/O операций и отдельных агентов для выполнения прикладной логики. Так, I/O-объекты будут вычитывать данные из сокетов и пересылать эти данные агентам. Агенты будут обрабатывать полученные от I/O-объектов данные, выполнять какую-то прикладную работу и будут генерировать ответные данные для отсылки. Отсылку же будут выполнять I/O-объекты. Может получиться что-то вроде:
// Сообщение для передачи прочитанных данных прикладному агенту.struct data_read final : public so_5::message_t {
std::vector<std::uint8_t> data_;
std::shared_ptr<connection_handler> io_handler_;
data_read(std::vector<std::uint8_t> data, std::shared_ptr<connection_handler> io_handler)
: data_(std::move(data)), io_handler_(std::move(io_handler))
{}
};
// Объект, который обрабатывает сокет.class connection_handler final : public std::enable_shared_from_this<connection_handler> {
asio::tcp::socket socket_;
asio::io_service::strand strand_;
...
so_5::mbox_t receiver_; // Адрес агента, которому нужно отсылать прочитанные данные.
...
std::vector<std::uint8_t> data_; // Буфер-приемник для чтения данных.
...
void start() {
// Начинаем читать входящие данные.
data_.resize(some_appropriate_size);
socket_.async_read_some(asio::buffer(data_),
strand_.wrap(std::bind(connection_handler::on_receive, shared_from_this(), _1, _2)));
...
}
void on_receive(const asio::error_code & ec, std::size_t bytes_received) {
if(!ec) {
// Отсылаем данные агенту для обработки.
data_.resize(bytes_received);
so_5::send<data_read>(receiver_, std::move(data_), shared_from_this());
}
else { /* Обработка ошибки */ }
}
...
};
// Агент, который получает входящие данные.class data_handler final : public so_5::agent_t {
public:
data_handler(context_t ctx, ...) : so_5::agent_t(std::move(ctx)), ... {
// Создаем подписку на прочитанные данные.
so_subscribe_self().event(data_handler::on_data_read);
...
}
...
private:
void on_data_read(mhood_t<data_read> cmd) {
...
}
};
В этом случае вообще нет надобности создавать thread_pool для Asio, достаточно будет и одной рабочей нити, на которой будет работать asio::io_service::run(). Ну а SO-шных агентов можно будет распределить по тем контекстам, которые им нужны. Тут от специфики задачи зависит.
Re[4]: Свежая статья (разбор примера machine_control)
S>Если же все-таки нужны кроме обработчиков I/O операций еще и акторы, то на данный момент единственный способ сделать такое -- это иметь отдельные объекты для I/O операций и отдельных агентов для выполнения прикладной логики. Так, I/O-объекты будут вычитывать данные из сокетов и пересылать эти данные агентам. Агенты будут обрабатывать полученные от I/O-объектов данные, выполнять какую-то прикладную работу и будут генерировать ответные данные для отсылки. Отсылку же будут выполнять I/O-объекты. Может получиться что-то вроде:
С отправкой агентам — все прозрачно, so_5::send<...> рещает проблему.
А как в обратную сторону передавать что-то I/O потокам в такой архитектуре?
Фактически идея — TCP/UDP прокси с агентами внутри для кеширования и другой логики.
Здравствуйте, dr. Acula, Вы писали:
DA>С отправкой агентам — все прозрачно, so_5::send<...> рещает проблему. DA>А как в обратную сторону передавать что-то I/O потокам в такой архитектуре?
Можно сделать как-то так (набросок): в сообщении data_read передается умный указатель на connection_handler. Поэтому у connection_handler-а можно дергать методы. Для того, чтобы инициировать запись со стороны агента в публичный интерфейс connection_handler добавляется вспомогательный метод initiate_write. Этот initiate_write задействует Asio-шный post для того, чтобы инициировать запись в сокет на контексте одного из I/O-потоков.
Получится, что агент дергает публичный метод connection_handler::initiate_write через умный указатель из сообщения data_read. Внутри initiate_write инициируется отложенная запись на контексте рабочих потоков Asio (т.е. что-то аналогичное so_5::send).
Тут фокус в том, чтобы не протухла ссылка на буфер с исходящими данными. Поэтому в наброске ниже я добавил в connection_handler поле outgoing_data_, в которое исходящие данные перемещаются перед записью. Если же возможна ситуация, когда агент может инициировать несколько send-ов (при этом следующий send может возникнуть еще до того, как закончится предыдущий), то нужно будет сделать какую-то более хитрую схему. Но это вряд ли будет представлять проблему. Так, initiate_write может постить через asio::post не вызов socket_.async_send, а операцию добавления очередного буфера в список буферов с исходящими данными. Тут большой простор для фантазии.
// Класс, который обрабатывает соединение.class connection_handler final : public std::enable_shared_from_this<connection_handler> {
asio::tcp::socket socket_;
...
std::vector<std::uint8_t> outgoing_data_;
public:
void initiate_write(std::vector<std::uint8_t> data) {
outgoing_data_ = std::move(data);
asio::post(socket_.get_executor(),
[self=shared_from_this()] {
self->socket_.async_send(
asio::buffer(self->outgoing_data_),
strand_.wrap(std::bind(connection_handler::on_sent, self, _1, _2)));
});
}
...
};
...
// Сообщение для передачи прочитанных данных прикладному агенту.struct data_read final : public so_5::message_t {
std::vector<std::uint8_t> data_;
std::shared_ptr<connection_handler> io_handler_;
data_read(std::vector<std::uint8_t> data, std::shared_ptr<connection_handler> io_handler)
: data_(std::move(data)), io_handler_(std::move(io_handler))
{}
};
...
// Класс агента, который обрабатывает данные.class data_handler final : public so_5::agent_t {
...
private:
void on_data_read(mhood_t<data_read> cmd) {
... // Какие-то действия над прочитанными данными.
// Здесь нам нужно записать что-то в ответ.
std::vector<std::uint8_t> outgoing_data{ ... };
cmd->io_handler_->initiate_write(std::move(outgoing_data));
}
};
Очередная статья, написанная на основе опыта работы с моделью акторов. На этот раз без какой-то жесткой привязки к C++ и SObjectizer-у. Так что, мы надеемся, она будет интересна большему кругу читателей: Объединяем акторов и SEDA-подход: зачем и как?
— однопоточная реализация 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, это наш косяк и мы его будем исправлять.
Со сроками официально релиза пока так: ориентировочно релиз состоится в первой декаде ноября. Если успеем раньше, выкатим раньше. Но там еще много работы, в том числе и по документированию, и по проверке сборки под Android с помощью Google-овского NDK и еще разных мелочей (и не мелочей). Так что первая декада ноября выглядит более реалистично.
В общем, если кому-то интересно, что в SObjectizer-е происходит, то смотрим, делимся впечатлениями и соображениями. Пока еще есть время и возможность повлиять на то, что попадет в SO-5.5.23 и so_5_extra-1.2.0.
Re[2]: SObjectizer 5.5.23-beta1 и so_5_extra-1.2.0-beta1
Здравствуйте, niXman, Вы писали:
X>так а для новых проектов какую версию SObjectizer предпочтительней использовать?
На данный момент стабильная версия 5.5.22.1. Ее и следует использовать.
Когда появится 5.5.23, можно будет на нее перейти. Вряд ли у вас сейчас будет необходимость использовать новую функциональность из 5.5.23.
На базе этой фичи в so_5_extra-1.2.0 реализовано несколько новых инструментов. Так, добавлена возможность отсылки сообщений, которые можно отозвать. Например:
// Отсылаем сообщение и сохраняем ID доставки.auto id = so_5::extra::revocable_msg::send<my_message>(mbox, ...);
... // Делаем что-то еще.if(some_condition())
// Решаем, что сообщение нужно отозвать.
id.revoke(); // Если сообщение еще не дошло до получателя,
// то оно будет отозвано и к получателю не попадет.
Отзывать можно и таймерные сообщения (т.е. отложенные и периодические). В этом случае сообщение будет отозвано даже если оно уже попало в очередь получателя (обычные таймерные сообщения в SObjectizer-е в этом случае до получателя все равно доходят).
Еще одна из новых фич so_5_extra -- возможность ограничить время доставки сообщения. Например, если сообщение не доставлено до получателя за 10 секунд, то оно выбрасывается и получателю уже не доставляется. Выглядит это так:
// Создаем экземпляр сообщения, которое хотим доставить.
so_5::extra::enveloped_msg::make<check_user>(...)
// ...теперь запаковываем его в специальный конверт...
.envelope<so_5::extra::enveloped_msg::time_limited_delivery_t>(10s)
// ...и отсылаем конверт с нашим сообщением..
.send_to(target_mbox);
Хочется поблагодарить не только тех людей, которые помогали нам с этим релизом. Но и вообще всех, кто проявлял интерес к SObjectizer-у все эти годы и находил время/возможность делится с нами своим впечатлениями, соображениями и идеями.
PS. SObjectizer-5.5 развивается уже больше четырех лет. И, вероятно, развитие ветки 5.5 подходит к своему логическому завершению. Если кому-то интересно посмотреть на то, что появилось в SO-5.5 за это время, то вот небольшой конспектик.
SObjectizer обновился до версии 5.5.24. Главное нововведение в этой версии -- это экспериментальная поддержка unit-тестирования для агентов. Подробнее эта возможность описана в отдельной статье. Если кому-то интересно, то попробуйте, поделитесь своими впечатлениями. Любой конструктивный фидбэк поможет нам сделать эту поддержку лучше и удобнее.
Также обновился сопутствующий проект so_5_extra: мы перевели его на более свежие версии зависимостей и добавили еще один пример в набор штатных примеров.
В течении ближайшей недели-двух мы планируем начать разработку SObjectizer-5.6, отказавшись от сохранения совместимости с веткой 5.5.
Причины, цели и некоторые ближайшие шаги описаны здесь. Если кому-то интересно повлиять на дальнейшее развитие SObjectizer-а, то можно отставить свои конструктивные соображения по указанной ссылке или прямо здесь.
Re: Рассказ об использовании SObjectizer-а в "дикой природе"
