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. В двух словах — это две совершенно разные разработки, ставящие перед собой разные цели и достигающие их разными способами. Подробнее здесь и здесь.

★★★★★

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 ()
Ответ на: комментарий от anonymous

самое интересное — шедулинг — у тебя потрогать нельзя

О чем здесь речь идет?

eao197 ★★★★★ ()
Ответ на: комментарий от 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 ★★★★★ ()
Ответ на: комментарий от dimon555

Насколько я понимаю, короткий ответ - «Да, порядок детерменирован, сообщения обработаются в том порядке, как они встали в очередь».

Если отвечать подробнее, то в So сообщения приходят не агенту, а в почтовый ящик, который отделен от агента (там не как в Qt, где сигналы приходят объекту, тут агент и ящик разные сущности). Агент подписан на сообщения в ящике, причем подписан лишь на определенные типы событий. Более того, один агент может получать события из разных ящиков. Также на события в одном ящике могут быть подписаны разные агенты (по сути ящик - это очередь, причем отдельная для каждого подписанного на события этого ящика агента, т.е. если один агент не успевает обрабатывать события, то других, подписанных на этот ящик, это не тормозит).

Агент, когда обрабатывает сообщения работает на каком-то потоке CPU, причем только на одном, т.е. только один экземпляр агента обрабатывает сообщения (даже если сообщения для него в ящике много). Но агент не напрямую привязан к определенному потоку, а через диспетчер. Их бывает несколько вариантов: все агенты а одном потоке, каждому - свой, на пачку агентов - пул потоков, но в любом случае, если агент уже работает на одном потоке, он же одновременно на другом не будет запущен. Так что из ящика агент достанет сообщение, запустится на каком-то потоке, обработает его, потом достанет следующее, запустится на, возможно, другом потоке и обработает его.

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

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

x_hash ()

Имея абсолютно ноль опыта с подобными библиотеками, libcaf показалась более интересной и доступной для понимания.

rupert ★★★★ ()

Я считаю, что новый фреймворк не нужен, так как привносит не свойственные языку понятия, концепции и способы программирования.

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

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

И? У вас на работе работают все C++ники мира? Почему вы думаете, что выборка по вашим коллегам будет репрезентативной?

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

Могли бы вы озвучить характер realtime-задач, которыми вам приходится заниматься?

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

И?

хамить изволим?

У вас на работе работают все C++ники мира?

нет. остальные — у меня.

дело в том, что среди крестовиков runtime как понятие используется довольно редко. мало кому с крестовым рантаймом приходится возиться, а как минимум половина, по моей оценке, весьма смутно представляют что это такое.

поэтому да, среди крестовиков rt — однозначно real-time.

вы же своей «библиотекой» притащили в кресты чуждые понятие, и вместо того чтобы как-то сблизить их с языком (пример немного более удачного интерфейса я приводил вчера), пытаетесь навязать ещё и чуждые сокращения.

вердикт. ненужно.

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

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

Есть агент-получатель aR, есть два независимых друг от друга сообщения m1 и m2.

Возможны две ситуации:

1. Сообщения m1 и m2 отправляются агенту aR с двух разных нитей. Т.е. операции deliver_message совершенно независимы друг от друга и осуществляются на независимых контекстах исполнения. В этом случае никакого детерминизма нет. Внутри deliver_message идет захват локов, в каком порядке ОС будет эти захваты обслуживать и какие нити будут приостановлены, а какие будут продолжать работать — только ОС знает.

2. Сообщения m1 и m2 отправляются агенту aR с одной нити. В этом случае порядок получения будет таким же, как и порядок отсылки.

Однако, возможно усложнение ситуации.

Если aR работает диспетчере adv_thread_pool, его обработчики для сообщений m1 и m2 помечены как thread_safe, то adv_thread_pool сможет попробовать вызвать обработчики m1 и m2 одновременно на контекстах разных рабочих нитей. И тут может произойти вот что:

  • сообщение m1 будет изъято из очереди первым, для него будет выбрана рабочая нить, сообщение будет передано этой нити, но нить не успеет вызвать обработчик m1 и будет вытеснена с процессора операционной системой;
  • сообщение m2 будет изъято из очереди следующим, для него будет выбрана другая рабочая нить, сообщение будет передано этой нити и обработчик m2 начнет свою работу;
  • через какое-то время ОС разбудит первую рабочую нить и начнется обработка m1.

Однако, по внешним наблюдениям будет создаваться впечатление, что m2 пошло на обработку до m1. Даже в случае, если m2 отсылалось позже m1 и стой же нити, где была отсылка m1.

Если такие фукусы многопоточности пользователя не устраивают, то в SO5 есть еще четыре штатных диспетчера, где таких вещей нет :)

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

нет. остальные — у меня.

Прошу прощения, но общение с Наполеонами — это не мой профиль.

Если вам кажется интерфейс библиотеки Theron более удачным, то просто используйте Theron и все.

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

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

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

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

На практике все несколько сложнее.

Сообщения из mbox-а (почтового ящика) раскидываются по агентам-получателям, а агенты раскидывают их по своим рабочим контекстам (для простоты можно считать рабочим нитям). И уже на рабочей нити будет одна общая очередь заявок для обработки сообщений всех получателей, привязанных к данной нити. Поэтому, если на сообщение подписано 100500 агентов и 100400 из них работает на одной рабочей нити, то все 100400 заявок будут стоять, в итоге, в одной общей очереди. Если один из агентов затормозит, то он приостановить работу других агентов на этом контексте.

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

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

Не скажу :)

Обработка как раз будет асинхронной :) Синхронным будет выглядеть запрос к агенту-обработчику. И пользоваться этой штукой как раз можно. А иногда и нужно, т.к. это хороший, простой и действенный способ борьбы с перегрузкой агентов.

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

Другое дело, что пользователю при использовании синхронных запросов придется гораздо больше думать о рабочих контекстах. Это да.

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

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

Ну понятно, мосье, что вы Д'Артаньян. Здесь почти 100% анонимусов таковыми являются.

Собственно, потому и анонимусы, что на словах все Д'Артаньяны.

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

если на сообщение подписано 100500 агентов и 100400 из них работает на одной рабочей нити, то все 100400 заявок будут стоять, в итоге, в одной общей очереди

ого. даже это ниасилил. фтопку, однозначно.

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

Имея абсолютно ноль опыта с подобными библиотеками, libcaf показалась более интересной и доступной для понимания.

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

Только вот есть у меня подозрение, что таковых в природе просто нет, т.к. сам libcaf был создан аспирантами и служил предметом диссертации, т.е. исследовательской работой. Как попытка реализовать Erlang средствами C++, наверное, это крутая работа. А вот как оно при работе над реальными проектами с обычными разработчиками (а не анонимными LOR-овскими мегаэкспертами) — ХЗ.

Вот, например, caf-овский паттерн-матчинг. Прикольно, наверное, сделать отсылку тупла (string, int, float) между двумя агентами. А что будет потом, когда этот тупл будут получать пять разных агентов, написанных разными людьми и находящихся в разных библиотеках? Насколько просто его будет поменять на (string, long long, double)? Или на (string, int, double, short)?

Какие инструменты помогут, например, проанализировать кодовую базу для построения списка всех используемых в приложении типов сообщений?

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

Или, к примеру, во что выльется реализация отсылки сообщения группе получателей в libcaf? Скажем, какой-то агент говорит группе подчиненных: внимание, пользователь хочет завершить приложение, давайте закругляйтесь со своей работой. В SO5 для этого есть обычный MPMC mbox, который доступен «из коробки», берешь и пользуешься. В libcaf все это нужно писать ручками.

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

Однако, повторюсь. SO5 и libcaf созданы для разных задач: SO5 для решения проблем concurrency, а libcaf для решения проблем parallel computing. В некоторых вещах эти проблемы пересекаются, но не более того.

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

ого. даже это ниасилил. фтопку, однозначно.

Нормально это асилили только в Erlang-е. Создав для этого собственный язык и собственный рантайм для него, который сам делает шедулинг по редукциям и имеет заточенный под эту специфику GC.

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

Я считаю, что новый фреймворк не нужен, так как привносит не свойственные языку понятия, концепции и способы программирования.

Интересно, а по поводу Qt вы что скажете?

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

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

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

Но, понятное дело, никому ничего не расскажете и не покажите.

Про хитрые реализации асинхронных агентов на C++ я тоже много слышал. Правда, всегда оказывалось, что все это a) привязано к конкретным возможностям конкретных ОС (а то и компилятора) и/или b) внутри этих агентов можно было дергать только определенный API, чтобы случайно не заблокировать хитрый кастомный шедулер какой-то длительной операцией ввода-вывода.

Все такие штуки были написаны под конкретную задачу и вне этой задачи никогда не жили.

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

никому ничего не расскажете

если вежливо попросишь — расскажу. что именно тебе непонятно в миграции акторов между потоками (между нодами)?

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

если вежливо попросишь — расскажу.

Ну-ну.

что именно тебе непонятно в миграции акторов между потоками (между нодами)?

Почему вам кажется, что мне что-то непонятно в миграции между потоками? В SO5 есть диспетчеры, которые это делают. А есть и те, что не делают.

Миграция между нодами пока не была нужна.

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

напомню с чего началась эта беседа

если на сообщение подписано 100500 агентов и 100400 из них работает на одной рабочей нити, то все 100400 заявок будут стоять, в итоге, в одной общей очереди

использовать взаимоисключающие параграфы — невежливо.

anonymous ()
Ответ на: напомню с чего началась эта беседа от anonymous

Вы, если беретесь цитировать, цитируйте все:

Сообщения из mbox-а (почтового ящика) раскидываются по агентам-получателям, а агенты раскидывают их по своим рабочим контекстам (для простоты можно считать рабочим нитям). И уже на рабочей нити будет одна общая очередь заявок для обработки сообщений всех получателей, привязанных к данной нити. Поэтому, если на сообщение подписано 100500 агентов и 100400 из них работает на одной рабочей нити, то все 100400 заявок будут стоять, в итоге, в одной общей очереди.

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

Но не обязательно они будут привязаны именно так. Пользователь управляет привязкой. Выбрал диспетчер one_thread для своих агентов, получил такую картину. Выбрал thread_pool, не получил.

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

ясно. вам, уважаемый, для начала стоит книжки почитать.

за сим откланиваюсь.

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

ясно. вам, уважаемый, для начала стоит книжки почитать.

Список рекомендуемой литературы — это тоже великая тайна всезнающих LOR-овских анонимусов?

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

Любому нормальному человеку приятна хвальба. Хвальба мотивирует на развитие проекта. А критика без предложений бессмысленна и непродуктивна.

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

Да, и добавлю, что привязываться к буквам (rt или realtime) - это бессмысленная и непродуктивная критика. Болтология, не имеющая отношения к делу и к сути проекта, и не помогающая ни заработать деньги, ни улучшить инструмент для их зарабатывания.

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

Не совсем так.

Хорошо, что о неоднозначности трактовки указывают.

Плохо то, что к SO5 это уже не имеет отношения. Что сделано, то сделано. Менять кучу кода из-за того, что кому-то на LOR-е показалось, что so_5::rt означает real-time — это несерьезно.

А вот на будущее учтем. Если будут какие-то серьезные переделки, можно будет либо от rt отказаться, либо заменить его на runtime или env (т.к. environment в данном случае является синонимом runtime).

eao197 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.