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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Допустим, есть некий объект 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();
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У тебя проблемы с восприятим критики твоего поделия. Ведёшь себя как девочка, честно.

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

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

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

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

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

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

Ну так на 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?

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

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

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

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

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

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

Это же LOR!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Слив засчитан, кукарекалка.

Болью будет попытка воссоздания аналога 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 как бы намекает, что это вполне возможно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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