LINUX.ORG.RU

SObjectizer v.5.5.19

 , , , ,


1

6

Сегодня мы официально выкатили очередную версию 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.19 описаны здесь.

Загрузить новую версию можно либо в виде архива с SourceForge, либо из svn-репозитория проекта, либо из зеркала на GitHub.

Между релизами 5.5.18 и 5.5.19 прошло довольно много времени, хотя на то были объективные причины. Надеемся, что работа над следующей версией, 5.5.20, пойдет быстрее и мы сможем выкатить ее в конце лета 2017-го.

Для будущей версии 5.5.20 у нас есть несколько своих идей, но в этом плане мы полностью открыты и готовы выслушать любые замечания и предложения. Так что, если кто-нибудь расскажет, что он хотел бы видеть в SObjectizer или, напротив, чего бы не хотел, то мы постараемся учесть это в своей работе. Опыт реализации таких фич, как отказ от дополнительного пространства имен so_5::rt, приоритеты агентов, иерархические конечные автоматы и мутабельные сообщения показывает, что это более чем возможно.

ЗЫ. Старую тему с анонсами SO-5 решил не поднимать, т.к. было это уже слишком давно. Для, кто не в курсе, что такое SObjectizer — это один из немногих живых и развивающихся OpenSource кросс-платформенных фреймворков для C++, которые дают разработчику возможность использовать Actor Model (в случае с SO-5 сюда добавляются еще и Pub/Sub, и CSP).

★★★★★

Во-первых, добавлена возможность запускать SObjectizer в однопоточном режиме.

Значит ли это, что я могу использовать SO-5 в вебе (используя emscripten)?

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

Поскольку никогда с emscripten и/или webasm не сталкивался, то сходу не скажу. Но если это направление интересно, то можно попробовать его прозондировать.

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

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

Ну мне c++ -> web интересно, поскольку наши плюсовые проекты собираются не только для мобилок, но и для веба.

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

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

В контексте того, что мы делаем, уместнее было бы говорить про Erlang.

Про переход с C++ на Scala — это вообще смешно. Язык такой же write-only, как и C++, да еще и прибитый гвоздями к JVM. Может это и не было фатальным недостатком лет 10 назад, но теперь нахер такое счастье.

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

Про интероперабельность не слышали? И в каком месте он write only? А работа в пространстве JVM - это плюс, а не минус. Написал код один раз и он работает везде, где есть JVM.

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

И в каком месте он write only?

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

А работа в пространстве JVM - это плюс, а не минус.

Ага, расскажите это тем, кто делает минималистичные приложения на Go для Docker-ов.

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

Вы со своей любовью к JVM опоздали лет на 15. Те проекты, которые было выгодно переводить с C++ на что-то другое, уже давным-давно перевели. И C++ остался только там, где его заменить либо пока нечем, либо эта замена обойдется ну очень уж дорого. Так что не напрягайтесь. Этот продукт для очень узкой прослойки C++ разработчиков.

eao197 ★★★★★ ()

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

Правильно ли я понял, что для этого необходима asio::io_service?

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

Правильно ли я понял, что для этого необходима asio::io_service?

Нет. SObjectizer способен работать на одной нити и без asio. Asio нужен для нашего http-фреймворка restinio, что и было показано в примере с http-сервером.

Вот минимальный пример, в котором никакой asio не нужен: https://sourceforge.net/p/sobjectizer/repo/HEAD/tree/tags/so_5/5.5.19/dev/sam...

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

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

P.S. Я как раз спрашивал про прикрутку многопроцессности к вашей либе. Думал попробовать внутри агентов позапускаскать процессы и попытаться пообщаться с ними посредством пайпов. Насколько я понял по презентации, это вполне реально.

kachsheev ★★ ()

Есть парочка вопросов:

1) А как вообще происходит версионирование? Просто судя по changelog изменения довольно сильные, а вы поменяли только последнюю цифру. Странно как-то или я не знаю вашей политики.

2) У Боргардта тоже что-то есть про акторы, я немного смотрел его код. Из разговоров с ним я понял, что он даже это успел кому-то продать. Рассматриваете ли вы его либу как конкурент или у вас всё слишком хорошо и от клиентов отбоя нет? :-)

3) Что насчёт рекламы? Как продвигать думаете? Или эта либа уже широкоизвестна в узких кругах?

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

Отличные.

Вот и славно :) Значит не зря готовился.

Я как раз спрашивал про прикрутку многопроцессности к вашей либе.

Да, помню, отличный вопрос.

У нас был вот такой эксперимент по прикручиванию MQTT-транспорта к SObjectizer: https://bitbucket.org/sobjectizerteam/mosquitto_transport-0.6 Но libmosquitto нас не сильно устраивает, так что есть большой соблазн развить все это дело в сторону собственной поддержки MQTT.

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

1) А как вообще происходит версионирование? Просто судя по changelog изменения довольно сильные, а вы поменяли только последнюю цифру. Странно как-то или я не знаю вашей политики.

У нас что-то по мотивам semver, только номер версии, по сути, из 4-х частей. Для semver у нас должно было бы быть что-то вроде SObjectizer-5 v.1.5.19. Но т.к. нам это не сильно нравится, то мы используем номера вида 5.5.17 (что тождественно 5.5.17.0), 5.5.17.1, 5.5.18 (что тождественно 5.5.18.0), 5.5.19 и т.д.

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

Если меняется вторая цифра, например, 5.4.* и 5.5.*, значит нарушена совместимость между версиями. При переходе с 5.4.* на 5.5.* нужно будет править код.

Если меняется третья цифра, например, 5.5.18 и 5.5.19, значит добавлена новая функциональность но совместимость на уровне исходников не сломана. Можно просто взять 5.5.19, перекомпилировать проект и все должно работать.

Если появляется/меняется четвертая цифра, например 5.5.17->5.5.17.1->5.5.17.2, то это говорит о баг-фиксах. Выкатили исправление ошибки, ничего не добавили, ничего не сломали.

2) У Боргардта тоже что-то есть про акторы, я немного смотрел его код. Из разговоров с ним я понял, что он даже это успел кому-то продать.

Я так понял, что его разработка используется в конторе, где он работает для выполнения внешних заказов. Т.е. к ним приходит клиент, они решают проблему клиента с помощью своей либы. Отсюда и «продажа».

Рассматриваете ли вы его либу как конкурент или у вас всё слишком хорошо и от клиентов отбоя нет? :-)

Мы вообще никого из C++ных проектов не рассматриваем как конкурентов. Во-первых, все живые разработки такого рода ну очень уж разные. Во-вторых, конкуренты для нас всех — это Erlang и Akka. Так что если какой-нибудь CAF или actor-zeta берет пользователей от Erlang/Akka и приводит в мир C++, то все от этого выигрывают.

3) Что насчёт рекламы? Как продвигать думаете? Или эта либа уже широкоизвестна в узких кругах?

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

Да, вроде как известность в узких кругах уже есть :)

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

Язык такой же write-only, как и C++

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

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

Не такой же.

Я рад, что вы так думаете, хотя ваше мнение по этому поводу мне было ну вот совершенно не интересно.

В теме про инструмент для C++ обсуждать Scala и JVM — это странно, по меньшей мере. Кто хочет писать на Scala, может с удовольствием это делать с использованием Akka, например.

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

В теме про инструмент для C++ обсуждать Scala и JVM — это странно, по меньшей мере.

Чувак, ты же не первый день на ЛОРе и сам знаешь, как это работает. Ты пишешь про свой инструмент, анонимус пишет что твой инструмент говно, как и C++, я его поддерживаю (реально ж говно этот ваш C++), после чего при удачном стечении обстоятельств начинается срач на 10-20-30 страниц. Так что давай, прекращай отлынивать.

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

Написал код один раз и

всю жизнь будешь таскать с собой Java Runtime, что влечет за собой, как минимум, большой размер дистрибутива (привет, докер) и долгий старт (привет cli утилиты типа систем сборки). Ну, и до кучи, миф про «работает везде» рассказывают те, кто никогда не ставил Java на FreeBSD, например (когда я это делал, это было так: скачай вручную отсюда инсталлятор и положи сюда, потому что лицензия не позволяет, затем вот отсюда патч, затем запусти обычную сборку, она еще скачает два патча, все соберет и получится в жопу дырявая полуторогодовалая версия Java, пользуйся). В реальности Java живет на Linux, Windows и Solaris, причем, насколько я понимаю, только x86. Это, конечно, больше, чем .Net, даже .Net Core, но все равно, до кроссплатформенности как до Китая пешком (.Net тоже пиарили: пишешь один раз и запускаешь на любой платформе, если эта платформа Windows). Так что сравни платформы, для которых есть C++ компилятор и JRE и не употребляй слова «кроссплатформенность» и «Java» в одном предложении. C++ уже давно самый кроссплатформенный язык, в котором есть как ассемблерные вставки, специфичные для конкретного железа, так и инструменты, которые позволяют писать код, работающий везде одинаково.

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

даладно. есть как мимнимум Раст и Ди еще.

Раст всё-таки от LLVM зависит, у плюсов это не единственный бекенд, а значит и охват платформ шире. Насчёт D не знаю.

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

Если мне и нужен срач на 20 страниц, так только на тему решения проблем concurrent computing в C++. Подчеркну, в C++.

Лол :-) Зачем кому-то тут обсуждать проблемы цепепе? :-) Такое обсуждается в узком кругу единомышленников на всяких там ваших конференциях по цепепе :-) Как сложить числа Фибоначчи с помощью шаблонной магии, как вычислить факториал, следуя правилам Александреску, как вывести на экран тип параметра шаблона через костыльный хак Мейерса :-) Проблем бесчисленное множество :-) Их можно обсуждать бесконечно, на фоне появления цепепе-21,25,29 и т.д. :-)

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

Есть HTTP сервер, на него приходят запросы (допустим GET и POST). Сервер знает два ящика: в один он кладёт get_request, в другой post_request. На каждое соединение создается mchain, который уходит вместе с *_request в ящик (как поле). Затем ожидается ответ из этого mchain, если его нет → соединение погибает.

Есть агент, a_handler, который подписывается на сообщения get_request и post_request.

Сейчас есть кооперация с двумя агентами типа a_handler: собственный ящик одного отдается серверу как ящик для get_request, а ящик второго для post_request.

Вот Сервер работает в 2 потока и обрабатывает очень-очень много соединений. Хотелось бы много агентов-обработчиков для get и парочка для post.

В том числе мне интересны разные варианты ответа на общую формулировку)

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

Есть, как минимум, три способа. Два простых, один посложнее.

Первый способ в том, чтобы использовать adv_thread_pool диспетчер и агента a_get_handler, у которого будут thread_safe обработчики сообщений get_request. Тогда нужен будет только один агент a_get_handler, события которого будут вызывать параллельно на нитях adv_thread_pool диспетчера. В этом способе программисту вообще ничего делать не нужно, но он не подходит, если обработчики для get_request нельзя сделать thread_safe.

Второй способ в том, чтобы ввести дополнительного агента a_get_handler_coordinator, под управлением которого будут работать N агентов a_get_handler. В этом случае сообщение get_request сперва отсылается на mbox a_get_handler_coordinator, а уже он выбирает подходящего a_get_handler (тут можно сделать несколько схем для выбора конкретного обработчика запроса).

Третий способ состоит в том, чтобы сделать свою реализацию интерфейса abstract_message_box_t, которая бы делала доставку сообщения до конкретного получателя согласно какой-то политике (например, посредством round-robin). Тут, правда, придется погрузиться в некоторые детали работы SO-5. Плюс к тому, к стабильности API таких внутренних классов мы относимся не так тщательно, как к API классов, предназначенных для непосредственного общения с пользователем. Поэтому может получиться так, что своя реализация mbox-а для 5.5.18 и 5.5.19 будет нуждаться в доработке напильником для 5.5.20.

В принципе, у нас есть в планах реализация round_robin_mbox-а как раз для таких целей. Но, скорее всего, это будет уже в дополнительном проекте so_5_extra, который будет содержать дополнительные надстройки над SO-5.

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

Вот, кстати, пара задокументированных примеров, которые показывают разные подходы к распределению нагрузки на нескольких «исполнителей»:

Collector and Many Performers

Redirect and Transform (здесь вообще хитрый подход используется, на основе лимитов сообщений и переадресации «лишних» сообщений следующему «исполнителю»).

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

thread_safe обработчики сообщений get_request.

Как пометить хендлер тред-сейф? Что-то надо будет сказать диспетчеру? Или всё автоматом заработает?

реализация round_robin_mbox-а

Было бы круто!

so_5_extra

А что там с лицензией?

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

Как пометить хендлер тред-сейф?

Указать флаг so_5::thread_safe при подписке события, например:

class cryptographer : public so_5::agent_t
{
   void on_make_signature( const make_signature & ) {...}
   void on_check_signature( const check_signature & ) {...}
...
   virtual void so_define_agent() override {
      so_subscribe_self()
        .event( &cryptographer::on_make_signature, so_5::thread_safe )
        .event( &cryptographer::on_check_signature, so_5::thread_safe )
      ...
   }
}
Подробнее здесь

Было бы круто!

Ну значит будет делать :) Кроме round-robin еще какие-нибудь политики интересны?

А что там с лицензией?

Пока все идет к тому, что будет двойная лицензия: GPL (или даже AGPL) для OpenSource и коммерческая для proprietary.

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

интереснее было бы MessagePack прикрутить.

Ну, мы в своем mosquitto_transport возню с encoding-ом отдаем на откуп пользователю (см. раздел «Message Encoding and Decoding Principles» в README.md). Для своих задач мы использовали JSON, поэтому на примере с JSON-ом в документации все и описывается. Но можно прикрутить и message pack, и protobuf, и cap'n'proto какой-нибудь.

eao197 ★★★★★ ()
Ответ на: комментарий от eao197
➤ uname -a
Linux pc 4.4.0-77-generic #98-Ubuntu SMP Wed Apr 26 08:34:02 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
➤ gcc --version 
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
BruteForce ★★★ ()
Ответ на: комментарий от BruteForce

А вот хз его знает. Они там живут уже несколько лет. Я -Werror использую только с clang, он меньше в диагностиках ошибается. До сих пор ни один из компиляторов не ругнулся.

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

eao197 ★★★★★ ()