LINUX.ORG.RU

Обновился инструмент для работы с агентами в C++: SObjectizer 5.5.0

 , , ,


4

1

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

Последние несколько лет SObjectizer развивается на SourceForge как OpenSource проект под BSD-лицензией. Подробнее об истории, текущем состоянии и направлении движения SObjectizer можно прочитать здесь.

Версия 5.5.0 является результатом очередного, очень значимого этапа развития проекта.

Главное отличие v.5.5.0 от предыдущих версий — это отсутствие зависимости от ACE Framework. Т.е. теперь ACE в коде ядра SObjectizer не используется вообще, для SObjectizer достаточно наличия стандартной библиотеки C++11. Это означает, что SObjectizer уменьшился в размере, нужно меньше времени на сборку SObjectizer-проектов, упрощается поддержка различных компиляторов и платформ. В частности, эта версия SObjectizer тестировалась посредством MSVS2013 (Windows), GCC 4.8/4.9 (Windows, Linux), Clang 3.5.0 (Linux).

Из более мелких изменений можно отметить прямую поддержку std::chrono при работе с отложенными/периодическими сообщениями, а так же небольшое изменение названий некоторых классов/функций (с сохранением старых имен для обеспечения совместимости). Более подробная информация о нововведениях в v.5.5.0 доступна в соответствующем разделе Wiki проекта. Так же увеличилось количество страниц с описаниями базовых вещей SObjectizer.

Версия 5.5.0 может быть загружена из раздела Files или получена из Subversion-репозитория.

Примечание. Этот релиз содержит только ядро SObjectizer (т.е. проект so_5). Никакие другие подпроекты (вроде so_log или so_sysconf) в релиз не включены. Возможно, сборка SObjectizer Assembly со всеми подпроектами будет сформирована и опубликована позже (если она действительно кому-то потребуется).

PS. Анонс делается просто для того, чтобы уведомить, что такой проект есть, живет, развивается. Доступен под BSD-лицензий, т.е. даром, в том числе и для коммерческих проектов. Это не просьба сделать code review. И не попытка кому-то что-то «продать».

PPS. Специально для желающих постебаться над синтаксисом и посравнивать программирование на C++ с Perl-ом. Вот классический пример Hello, World. В традиционном, ООП-шном варианте, с созданием класса агента и переопределением виртуальных методов (хотя есть и более модерновый вариант, с использованием С++ных лямбда-функций):

#include <iostream>

// Main SObjectizer header files.
#include <so_5/all.hpp>

// Definition of an agent for SObjectizer.
class a_hello_t : public so_5::rt::agent_t
{
	public:
		a_hello_t( so_5::rt::environment_t & env )
			: so_5::rt::agent_t( env )
		{}

		// A reaction to start of work in SObjectizer.
		virtual void
		so_evt_start() override
		{
			std::cout << "Hello, world! This is SObjectizer v.5."
				<< std::endl;

			// Shutting down SObjectizer.
			so_environment().stop();
		}

		// A reaction to finish of work in SObjectizer.
		virtual void
		so_evt_finish() override
		{
			std::cout << "Bye! This was SObjectizer v.5."
				<< std::endl;
		}
};

int
main( int, char ** )
{
	try
	{
		// Starting SObjectizer.
		so_5::launch(
			// A function for SO Environment initialization.
			[]( so_5::rt::environment_t & env )
			{
				// Creating and registering single agent as a cooperation.
				env.register_agent_as_coop( "coop", new a_hello_t( env ) );
			} );
	}
	catch( const std::exception & ex )
	{
		std::cerr << "Error: " << ex.what() << std::endl;
		return 1;
	}

	return 0;
}

PPPS. Специально для желающих узнать, чем SObjectizer лучше libcppa/CAF. В двух словах — это две совершенно разные разработки, ставящие перед собой разные цели и достигающие их разными способами. Подробнее здесь и здесь.

★★★★★

Последнее исправление: beastie (всего исправлений: 2)

so_5::rt::environment_t

rt - это сокращение от runtime? Если да, то убейтесь об стену.

З.Ы. Это чемпионат по самым сложным hello world на C++?

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

rt - это сокращение от runtime?

Да.

Если да,

Можете предложить что-то лучше?

то убейтесь об стену.

Только после вас.

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

rt - это сокращение от runtime? Если да, то убейтесь об стену.

Поясни, что с этим не так?

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

Это чемпионат по самым сложным hello world на C++?

Целью разработки SObjectizer было вовсе не написание примеров вроде «hello, world». Равно как и целью разработки языка C не было написание программы «hello, world» с которой уже больше 40 лет люди начинают изучение этого языка. Данный код всего лишь является данью традиции показывать что-то очень простое с помощью самых базовых вещей.

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

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

Можете предложить что-то лучше?

Вы клавиатуру бережете, что «runtime» писать сложно? rt - общепринятое сокращение от Real-Time. И никак не run-time.

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

Не, я просто стебусь с примеров, которые ничего не показывают, но при этом очень стараются вырвать гланды через жопу.

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

rt - общепринятое сокращение от Real-Time

С учетом того, что людей, реально занимающихся Real-Time, очень и очень мало, то это общепринятое сокращение в очень узких кругах. А для большинства разработчиков rt с таким же успехом может быть расшифровано и как run-time. Тем более, что это идет в рамках фреймворка, который никаких рилтаймовых гарантий не дает и к рилтайму не имеет отношения от слова совсем.

Экономия не на клавиатуре, а на восприятии. Исходный текст, в котором полно so_5::runtime:: воспринимается несколько хуже, чем текст с so_5::rt::

PS. Насколько я помню, сам по себе термин real-time не имеет смысла. В отличии от терминов hard real-time и soft real-time.

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

Ну это понятно.

Над классическим Hello, World для C++ нет желания постебаться? Он же показывает не больше. А по сравнению с каким-нибудь Ruby/Python еще и образец чрезмерного синтаксического оверхеда...

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

В топике идет речь про «разработку событийно-ориентированных приложений, для параллельной и независимой обработки событий в которых требуется многопоточность и/или распределенность», так что вполне можно подумать что есть реалтаймовый вариант окружения. Но потом опять подумать и понять что все-таки это runtime. :)

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

В разработке софта есть несколько фундаментальных, трудно разрешимых проблем: поиск адекватно оценивающих себя людей, предсказание сроков разработки, выбор удачных имен для идентификаторов...

Данный спор как раз последнюю проблему и иллюстрирует. Какое бы имя не было выбрано, всегда найдутся люди, котором оно не понравится.

:)

eao197 ★★★★★
() автор топика

1. зачем оно вообще нужно? написать крестовые акторы на коленке — дело пары часов/дней (в зависимости от того что нужно). самое интересное — шедулинг — у тебя потрогать нельзя, что может сильно испортить настроение при попытке запустить эту марахайку не на локалхосте, а на кластере.

2. такой хеллоу-ворлд мне более по нраву: http://www.theron-library.com/index.php?t=page&p=hello world

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

настраиваемая под конкретную задачу:

1. приоритезация доставки сообщений

2. выбор наиболее подходящей ноды из равноценных

м?

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

1. приоритезация доставки сообщений

Приоритеты для сообщений в SO5 не поддерживаются. Поддерживались в SO4, пользы от них не было, накладные расходы были. Отказались за ненадобностью, пожалеть не пришлось.

2. выбор наиболее подходящей ноды из равноценных

Вообще-то SO5 — это не Erlang-овский ОТР, не MPI, не MQ-сервис (вроде RabbitMQ, WebSphere MQ или Tibco Rendezvois). И даже не одна из реализаций FIPA агентов.

Само ядро SO5 отвечает только за предоставление агентам возможности асинхронно обрабатывать отосланные им сообщения/запросы. Не более того. Наверх можно прикручивать разные вещи, чем мы в прошлом и занимались. В том числе сделав и библиотеку для обмена сообщениями между расположенными на разных узлах агентами. Эта библиотека поддерживалась до SO-5.4. Что с ней будет дальше — вопрос. Возможно, вообще ничего и для построения распределенных приложений будет задействовано что-то внешнее (AMQP, MQTT, DDS и т.д.)

1. зачем оно вообще нужно? написать крестовые акторы на коленке — дело пары часов/дней (в зависимости от того что нужно).

Объемы исходных текстов тех же CAF и Theron показывают, что это далеко не так.

2. такой хеллоу-ворлд мне более по нраву: http://www.theron-library.com/index.php?t=page&p=hello world

В принципе, Theron отличается от libcppa/CAF настолько же сильно, насколько и SObjectizer. В чем-то Theron похож на SO.

Но это не тот же самый пример. В примере Theron-а показана отсылка приветственного сообщения агенту. В примере из SO5 задействуется стандартная фича агентов SO5 — методы so_evt_start/so_evt_finish вызываются автоматически при старте/завершении работы агента внутри рантайма.

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

пользы от них не было, накладные расходы были.

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

возможности асинхронно обрабатывать отосланные им сообщения/запросы

это пока из детских штанишек не вырос. есть у меня агент poop, но ему начали наваливать столько, что один не справляется никак. в high-load/big-data такое на каждом шагу. poop1, poop2... — не выход. тогда я притащу внутрь агентов общую информацию о системе, чем полностью похерю смысл акторов.

Объемы исходных текстов тех же CAF и Theron показывают, что это далеко не так.

это потому, что оба они, как и твоё творение — фреймворки. и судьба у них одинаковая — ты же сам знаешь на примере ace (а он в своё время считался достаточно качественным. сам не пользовался — это мнение людей, которым у меня есть основания доверять) ;)

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

будет задействовано что-то внешнее (AMQP

оригинальная идея. ничего, что он уже (в виде rabbitmq) умеет практически всё то же самое, и ещё много чего?

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

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

О чем это вы? Откуда вы знаете, как работа с приоритетами сообщений строилась в SO4?

это пока из детских штанишек не вырос. есть у меня агент poop, но ему начали наваливать столько, что один не справляется никак. в high-load/big-data такое на каждом шагу. poop1, poop2... — не выход. тогда я притащу внутрь агентов общую информацию о системе, чем полностью похерю смысл акторов.

Это вы переносите на агентов вообще свой личный взгляд на то, как вам удобно. Проблемы overload control можно решать разными способами.

ты же сам знаешь на примере ace (а он в своё время считался достаточно качественным. сам не пользовался — это мнение людей, которым у меня есть основания доверять)

ACE вполне себе нормальный фреймворк и разбираться в нем, при необходимости, можно было намного проще, чем в том же Boost-е. В чем были претензии к ACE, так это к скорости реакции на баги и патчи.

Отказ от ACE вызван не столько проблемами ACE, сколько мыслью о том, что SO5 без ACE будет интереснее и его будет проще портировать на другие платформы/компиляторы. Что, кмк, близко к истине.

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

оригинальная идея. ничего, что он уже (в виде rabbitmq) умеет практически всё то же самое, и ещё много чего?

Как раз то, что умеет rabbit и нет смысла дальше поддерживать в SO5. А вот диспетчеров для агентов внутри приложения-клиента, как я понимаю, в rabbit-е нет и не будет.

eao197 ★★★★★
() автор топика

Зря все на опа набросились, полезный проект. Больше акторов для бога акторов! Не OTP, но самое то для обычных гуевых многопоточных приложений, где есть пул рабочих процессов, и контролирующий их gui, на QT каком-нибудь.

Что к вас с поддержкой MS VS? Собирается? Потому что libcppa не собирается.

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

Что к вас с поддержкой MS VS? Собирается?

Компилятор из MSVS2013 поддерживается, один из основных при разработке. Но .sln-файлов нет.

Потому что libcppa не собирается.

И до выхода MSVS2014 не будет. Да и после выхода не понятно, они же там возможности C++11 по полной программе насилуют, не факт, что уровень поддержки в VC++ их устроит.

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

Зря все на опа набросились, полезный проект.

А вот скажи - нахрена ОПу хвальба? От нее, в отличие от критики, толку никакого.

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

QT

Дай угадаю - ты его еще и произносишь как «кьюте», да?

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

в очень узких кругах.

Был бы я сейчас на работе, произвел бы тебе выбрку senior-плюсовиков, и оказалось бы, что 100% знают, что rt - это real-time. И ровно никто не встречал бы расшифровку как runtime.

Насколько я помню, сам по себе термин real-time не имеет смысла. В отличии от терминов hard real-time и soft real-time.

Вполне имеет. Обычно это именно сокращение, причем какой именно (hard/soft, в реальной жизни почти всегда hard) - ясно по контексту.

Pavval ★★★★★
()

если к одному агенту придёт два сообщения в одно и то же время, то детерминирован ли порядок их обработки?

dimon555 ★★★★★
()