LINUX.ORG.RU

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

 , , ,


1

2

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

Проект живет на SourceForge, распространяется под трехпунктной BSD-лицензией.

Версию 5.5.5 можно взять либо из секции Files на SF, либо из Svn-репозитория, либо из зеркала на GitHub.

Если говорить кратко, то в версии 5.5.5 появилось следующее:

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

Так же подготовлены две новые части серии презентаций “Dive into SObjectizer-5.5”, более подробно рассказывающие о состояниях агентов и кооперациях агентов (все имеющиеся презентации собраны здесь).

Если интересны подробности, то сюда.

Отдельная благодарность Алексею Сырникову, как за помощь в подготовке этого релиза, так и за поддержку зеркала SObjectizer на GitHub-е.

★★★★★

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

...и мне более чем достаточно SF

Ох, ё-моё! Я не один такой?!!! :)

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

Блин, несколько раз уже пытался что-то наваять с этим SO (Конкретно - RPC), так и не осилил его понять. А вот в CAF врубился сразу. Как-то он логичнее, чтоль и это несмотря на то, что английский мой 3 иностранный язык и зная я его на уровне A2 пока.

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

Блин, несколько раз уже пытался что-то наваять с этим SO (Конкретно - RPC), так и не осилил его понять.

Интересно, а как вы пытались делать RPC, если в SO уже давно нет механизмов IPC?

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

IPC у меня свой есть. Мне нужны были слоты чтоб доставлять колбеки в тот самый поток, из которого был сделан вызов, например. Ну и простое ожидание ответа. Сейчас у меня обычная очередь с таймаутами и не сильно эффективная. По-уму хотел все сделать :)

Сериализатор - протобуф, IPC - tcp/unixsocket/winpipe.

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

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

Т.е., по сути, вам нужны были синхронные взаимодействия между потоками?

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

Грубо говоря - да. Сделал запрос - подождал ответ, вернул управление. В момент ожидания можно выполнять колбеки, посланные в этот же поток с другой стороны, либо исполнять другие вызовы.

Обычный такой RPC.

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

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

И да, это сейчас был аргумент в пользу спп или в пользу со5? Я как бы намекаю, что если тебе нужны акторы бери эрланг и вперёд. А если производильность то бери спп и дрочи регистры, а не акторы там всякие.

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

Сделал запрос - подождал ответ, вернул управление. В момент ожидания можно выполнять колбеки, посланные в этот же поток с другой стороны, либо исполнять другие вызовы.

Походу я что-то торможу. Или воспринимаю ситуацию сложнее, чем она есть.

Допустим, есть некий объект A, который работает на рабочем потоке T1. Этому объекту A нужно обратиться к объекту B, работающем на потоке T2.

Получается что-то вроде:

void A::some_operation() {
  // Sending request to B.
  future<Reply> r = send_request_to(B);
  // Waiting for actual reply.
  r.get();
}
Но ведь в момент, пока будет работать future<Reply>::get() у вас же рабочий поток T1 будет заблокирован. Как вы будете выполнять какие-то другие действия в ожидании ответа?

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

Миллион молчит, потому что всё работает, а два индивида устраивают срач в блогосфере. И тут ты такой: кококо, эрлангеры разочаровались в эрланге! Сенсация интриги расследавания! Свежий выпуск со5!

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

В этом и суть. Reply может быть не совсем Reply. И future тут не совсем подходит.

Например, если вместо Reply я получаю ReplyCall, то исполняю его и снова жду свой Reply. Как-то так. то есть я читаю слот до тех пор пока не увижу там ответ. Все остальное я исполняю «здесь и сейчас», либо отдаю на исполнение в другой поток, либо еще что-то.

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

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

У вас с логикой все нормально? А то «дебилизм» и «почему на пип» в одном абзаце как-то странным образом уживаются.

PHP в FB — это тоже самое, что Ruby в Twitter-е. Или Python в Google. Только Ruby в Twitter-е на Scala заменили, Python в Google на Go заменяют.

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

Эта точка зрения понятна. Не нова. И не является решением на все случаи жизни.

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

Например, если вместо Reply я получаю ReplyCall, то исполняю его и снова жду свой Reply. Как-то так. то есть я читаю слот до тех пор пока не увижу там ответ. Все остальное я исполняю «здесь и сейчас», либо отдаю на исполнение в другой поток, либо еще что-то.

Т.е. на уровне псевдокода получается что-то вроде:

void A::main_loop() {
  while(!slot_.eof()) {
    slot_.get_and_process(
      [=]( Reply & reply ) { /* Handle reply. */ },
      [=]( ReplyCall & call ) { /* Handle call. */ },
      [=]( SomethingElse & dummy ) { ... },
      ... );
  }
}

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

Я тебе запрещаю на с писать? Любой нативный язык, который умеет байтодрочево с ссе бери. Можеж считать это тем, что в расте называют ансейф.

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

Миллион молчит, потому что всё работает

Миллионы мух не могут ошибаться?

Откуда, кстати, вести о том, что эрлангом пользуются миллионы разработчиков? Анонимная LOR-овская аналитика или таки есть ссылки на что-то более заслуживающее доверия?

а два индивида устраивают срач в блогосфере.
Свежий выпуск со5!

Это вообще не связанные друг с другом вещи. Которые могут связаться только в головах шибко умных анонимов с LOR-а.

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

Какая разница миллион или не миллион. Ты делаешь вывод на основе единичного случая. Ты же не знаешь, что я например за вчера написал на эрланге то, что ты бы на спп делал бы неделю? Или мне теперь трезвонить об везде на лево и на право?

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

Какая разница миллион или не миллион.

Например, разница на порядок.

Ты делаешь вывод на основе единичного случая.

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

Ты же не знаешь, что я например за вчера написал на эрланге то, что ты бы на спп делал бы неделю?

Более того, я не знаю, что вы вообще что-то делаете, кроме пустого трындежа на LOR-е. Может вы умеете программировать, может нет. Это равновероятно.

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

С логикой у меня всё типтоп. Если ты делаешь стартап на три с половиной юзера, то хоть на вб пиши, или вообще найми телефонистку из китая, лишь быстрее написать, что бы уменшить стоимость разработки и прочее. Но после того, как твой стартап достиг скажем надцать ионов запросов, вот тогда начинаются мысли о производительности. На сцену выходит спп. Потому что на сёднешний день ничего другого нет. Что тут не логичного?

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

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

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

Впрочем, это уже злобный оффтопик.

Не оффтопик то, что есть задачи, в которых производительность важна с самого начала. И для них C++ в качестве языка реализации стоит в одном ряду с C, Java/Scala, C#, а то и впереди них.

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

Точно так. Очень похоже на то, что есть сейчас.

Ну так на SO у вас бы было очень похоже:

void A::so_define_agent() override {
  so_subscribe_self()
    .event( [=]( const Reply & evt ) {...} )
    .event( [=]( const ReplyCall & evt ) {...} )
    .event( [=]( const SomethingElse & evt ) {...} )
    ...;
}
Или, если обработчики имеют приличный объем и их выгодно вынести в отдельные методы:
void A::so_define_agent() override {
  so_subscribe_self()
    .event( &A::evt_reply )
    .event( &A::evt_reply_call )
    .event( &A::evt_something_else )
    ...;
}
void A::evt_reply( const Reply & evt ) {...}
void A::evt_reply_call( const ReplyCall & evt ) {...}
void A::evt_something_else( const SomethingElse & evt ) {...}

Кстати, если у вас в IPC есть winpipe, как вы CAF под Windows собираете, через MinGW?

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

У тебя проблемы с восприятим критики твоего поделия.

С критикой проблем нет.

Только вот называть попытки обмазывания говном критикой я бы не стал.

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

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

Почему? Что за кидания в крайности? Почему нельзя взять C++, использовать там акторы и получить более производительную систему, в том случае, если фичи плюсов тебе вцелом в данной системе важны? Что за религиозный фундаментализм?

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

Что за религиозный фундаментализм?

Это же LOR!

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

Потому что эрланг простой как дерево, там даже уб нету, в отличии от. Я уже молчу про количество букв кода, которые нужно банально на клаве наклацать. А меньше кода - меньше багов.

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

Я уже молчу про количество букв кода, которые нужно банально на клаве наклацать. А меньше кода - меньше багов.

Если вас устраивает динамическая типизация в Erlang-е, его производительность, ресурсоемкость и качество сторонних библиотек, то у вас все в порядке. Зачем вы тогда участвуете в теме, посвященной инструменту для C++?

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

Почему нельзя взять C++, использовать там акторы и получить более производительную систему,

Почему все разговоры про Erlang сводятся к производительности? Если нода на Erlang'e не может прокачать канал то юзай NIF'ки, драйвера и узлы на C. Зачем городить все на С++ и создавать себе головную боль?

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

Зачем городить все на С++ и создавать себе головную боль?

Почему вы считаете, что программирование на C++ неразрывно связано с головной болью?

И если в C++ все так плохо, почему вы считаете, что NIF-и и драйвера на C, написанные Erlang-ерами, будут лучшего качества?

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

Этож ЛОР. Ыксперт сказал «боль» - значит у всех «боль». Ыксперт ниосилил - значит непригодно пользовать инструмент.

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

Ыксперт ниосилил - значит непригодно пользовать инструмент.

Ну так не понятно же: писать на C++ — боль, а писать на C узкие места для Erlang-а — уже не боль :)

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

Почему вы считаете, что программирование на C++ неразрывно связано с головной болью?

Болью будет попытка воссоздания аналога OTP и распределенных фич Эрланга. Или вы считаете что это просто?

И если в C++ все так плохо, почему вы считаете, что NIF-и и драйвера на C, написанные Erlang-ерами, будут лучшего качества?

О С++ я говорю в рамках поста анона, на С воспроизведение инфраструктуры Ерланга будет еще большей болью для разрабов. Что проще, написать такую систему с нуля или написать драйвер специально для узкого места в производительности? Этот драйвер может даже просто стороннюю либу дергать (как обычно и происходит) и содержать в себе 200 строчек кода.

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

Пример чего-либо сравнимого с Erlang/OTP на С++. Чтоб все «из коробки».

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

Глаза разуй и посмотри что я говорил в ответ на этот пост:

Почему? Что за кидания в крайности? Почему нельзя взять C++, использовать там акторы и получить более производительную систему, в том случае, если фичи плюсов тебе вцелом в данной системе важны? Что за религиозный фундаментализм?

Речь идет о создании на С++ всего что умеет Erlang.

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

получить более производительную систему

читай слова, ушлепок, или русский у тебя не родной

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

Болью будет попытка воссоздания аналога OTP и распределенных фич Эрланга.
Речь идет о создании на С++ всего что умеет Erlang.

А где речь идет о «создании на C++ всего, что умеет Erlang»?

Обсуждаемый здесь инструмент, а именно SO-5.5.5, предназначен для предоставления возможности обмена асинхронными сообщениями внутри одного процесса. Его задача — дать разработчику средства для отправки сообщений и предоставление контекста для их обработки. И чтобы это не выглядело как:

some_queue.push( new MyMessage(...) );
...
Message * msg = some_queue.pop();
if( MyMessage::type == msg->type() )
{
  process_my_message( dynamic_cast<MyMessage*>(msg) );
  delete msg;
}
else ...

Пример чего-либо сравнимого с Erlang/OTP на С++.
Или вы считаете что это просто?

Во-первых, подход Erlang/OTP не единственный возможный. Во-вторых, опыт Ice от ZeroC, Akka и Could Haskell как бы намекает, что это вполне возможно.

eao197 ★★★★★
() автор топика
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от anonymous

Что такое «более производительную система», идиот? Или ты кроме локалхоста ничего не видел? Локалхостопроблемы эрлангистов не волнуют.

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

А где речь идет о «создании на C++ всего, что умеет Erlang»?

Почему нельзя взять C++, использовать там акторы и получить более производительную систему, в том случае, если фичи плюсов тебе вцелом в данной системе важны?

Систему. Системой на Эрланге может быть как один занюханный сервак, так и кластер.

К самому SO никаких вопросов не имею абсолютно. Каждой задаче - свой инструмент. Распределенную систему на Эрланге построить проще, чем на С++. Это факт. Узкие места в производительности на конкретном узле в Эрланге решаются NIF'ками, драйверами и С-узлами.

Во-первых, подход Erlang/OTP не единственный возможный. Во-вторых, опыт Ice от ZeroC, Akka и Could Haskell как бы намекает, что это вполне возможно.

Первый гляну, но там пока не вижу средств по контролю за узлами кластера (мельком просто глянул). Остальные не на С++.

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

Систему. Системой на Эрланге может быть как один занюханный сервак, так и кластер.

Это вообще-то очень узкое понятие системы. Оно имело бы место, если бы речь шла о распределенном приложении.

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

Остальные не на С++.

Я специально указал на инструменты для разных языков, чтобы показать, что подход Erlang/OTP не единственный возможный и под любой высокоуровневый язык можно создать инструменты для разработки распределенных приложений.

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

Есть еще, например, область распределенных вычислений, которая покрывается MPI, в которой слежение за кластером так же не является первоочередной задачей, насколько я помню.

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

Мы в свое время на SO спокойно создавали распределенные приложения

Вывсёврети! Явамниверю! только ерланк так умеет! на с++ кококо и боль, професианалы неодобряэ!

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

Это вообще-то очень узкое понятие системы. Оно имело бы место, если бы речь шла о распределенном приложении.

Речь шла об Эрланге, значит речь идет о распределенной отказоустойчивой системе. И тут появляется анон на белом коне и говорит о том что на С++ производительнее - все пишем на нем. Но что поделаешь - мозгов у анона мало.

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

У вас контролировалось внешним инструментом все, узел отвалился - его кто-то перезапускал. А в Erlang'e это все уже внутри.

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

пока не вижу средств по контролю за узлами кластера (мельком просто глянул)

Ключевое слово для поиска, насколько я помню, IceGrid.

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

Речь шла об Эрланге, значит речь идет о распределенной отказоустойчивой системе.

Вообще-то изначально речь шла о C++ :)

Это уже затем подтянулись анонимы, которые приплели Erlang. Ну а потом уже...

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

А в Erlang'e это все уже внутри.

После восстановления физического узла кто-то же все равно должен поднимать Erlang-овскую VM. Так какая разница, поднимается ли Erlang-овская VM или C++ный процесс?

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

Речь шла об Эрланге

Речь шла о SO 5.5.5, И тут появляется некий мукдак на белом коне и говорит о том что на ерланк лучше - все пишем на нем. Но что поделаешь - мозгов у мукдака мало и, очевидно, неудовлетворенность жизнью и другие комплексы, если он везде свой ерланк суёт.

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

После восстановления физического узла кто-то же все равно должен поднимать Erlang-овскую VM. Так какая разница, поднимается ли Erlang-овская VM или C++ный процесс?

Ну если уж узел физически недоступен... То да, разницы нет. Но вполне может отлететь ПО на узле. А вот его уже можно и автоматикой на Эрланге поднимать.

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

речь идет о распределенной отказоустойчивой системе.

Кстати говоря, вспомнилась еще одна штука, тесно связанная с еще одной нишей распределенных отказоустойчивых систем: Data Distribution Standard for Real-Time Systems (подборку интересных PDF-ок я делал около года назад).

Там сейчас очень и очень плотно сидят C, C++ и Java, насколько я помню. И задачи с помощью DDS решают довольно таки нешуточные.

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

А вот его уже можно и автоматикой на Эрланге поднимать.

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

Соответственно, мы можем любую, мало-мальски самостоятельную активность оформлять в виде Erlang-овского процесса. Пусть хоть таких процессов будет 100K в одной VM, не страшно. Специально заточенный run-time, который обеспечивает вытесняющую многозадачность для Erlang-овых процессов, эффективная сборка мусора, использующая особенности изоляции процессов, разработка самих процессов в функциональном стиле... Все это ведет к тому, что если процесс падает, то просто так навредить другим процессам в той же VM он не может (если только он не упал при записи какой-нибудь гадости в разделяемую между несколькими процессами mnesia).

В C++ такой подход вряд ли уместен. Т.е. C++ные фреймворки вроде SO-5 или CAF позволяют оформить мало-мальски самостоятельные активности в отдельные объекты-агенты (акторы), но:

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

- агенты/акторы в C++ных фреймворках не будут изолированы. Поэтому, если какой-то агент «грохнется» из-за исключения и не обеспечит при этом хотя бы базовую гарантию безопасности, то из-за порчи памяти, например, приложение может загнуться когда-нибудь и где-нибудь в другом месте.

Поэтому разработка приложения в акторах на C++ будет отличаться от таковой в Erlang-е (и даже в Akka).

Ну а т.к. при использовании принципа fail-fast падение процесса вполне допустимо, то на узле кластера вполне может стоять какой-то супервизор, который будет рестартовать упавший процесс. Такие супервизоры есть готовые, да и сделать такой на коленке не большая проблема.

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

Потому что эрланг простой как дерево, там даже уб нету, в отличии от. Я уже молчу про количество букв кода, которые нужно банально на клаве наклацать. А меньше кода - меньше багов.

Это не ответ на вопрос.

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

Почему все разговоры про Erlang сводятся к производительности?

Это разговор о C++ и библиотеке акторов для него. Тут говорят, что вместо этого нужно взять Erlang. Почему - не объясняют. Erlang хороший инструмент, с этим никто не спорит. И никто не говорит, что C++ лучше. Они разные. Для разных задач. Но и там и там могут быть полезны акторы.

Зачем городить все на С++ и создавать себе головную боль?

Какую боль? C++ инструмент для определенного круга задач. И почему там не могут быть полезны акторы? Или почему я вдруг должен брать erlang, если он мне в данной задаче как собаке пятая нога? Только ради акторной модели? Глупо.

Еще раз, тут никто не отрицает достоинства Erlang'а.

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

Болью будет попытка воссоздания аналога OTP и распределенных фич Эрланга. Или вы считаете что это просто?

А зачем что-то воссоздавать?

О С++ я говорю в рамках поста анона

Пост анона был ответом на пост о том, что «если вам нужны акторы, то берите erlang, а не C++».

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