• Пишем собственный хитрый thread_pool-диспетчер для SObjectizer-а

      О чем эта статья?


      Одной из основных отличительных черт C++ного фреймворка SObjectizer является наличие диспетчеров. Диспетчеры определяют где и как акторы (агенты в терминологии SObjectizer-а) будут обрабатывать свои события: на отдельной нити, на пуле рабочих нитей, на одной общей для группы акторов нити и т.д.

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

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

      Преамбула


      Недавно один из пользователей SObjectizer-а рассказал про специфическую проблему, с которой ему довелось столкнуться в процессе использования SObjectizer-а. Смысл в том, что на базе SObjectizer-овских агентов разрабатывается приложение для управления подключенными к компьютеру устройствами. Часть операций (а именно операция инициализации и переинициализации устройства) выполняется синхронно, что приводит к блокировке рабочей нити на некоторое время. Операции же ввода-вывода осуществляются асинхронно, поэтому иницирование чтения/записи и обработка результата чтения-записи выполняются значительно быстрее и не блокируют рабочую нить надолго.
      Читать дальше →
    • Когда акторный фреймворк превращается в «черный ящик» и что мы можем с этим сделать?

        Модель акторов — это хороший подход к решению некоторых типов задач. Готовый акторный фреймворк, особенно в случае языка C++, может очень сильно облегчить жизнь разработчика. С программиста снимается изрядная часть забот по управлению рабочими контекстами, организации очередей сообщений, контролю за временем жизни сообщений и т.д. Но, как говорится, все хорошее в этой жизни либо противозаконно, либо аморально, либо ведет к ожирению ничего не дается бесплатно. Одна из проблем использования готового (т.е. чужого) акторного фреймворка состоит в том, что иногда он превращается в «черный ящик». Ты видишь, что ты отдаешь в этот «черный ящик», ты видишь, что из него приходит (если вообще приходит). Но далеко не всегда понятно, как из первого получается второе…
        Читать дальше →
        • +14
        • 2,3k
        • 1
      • Асинхронные HTTP-запросы на C++: входящие через RESTinio, исходящие через libcurl. Часть 3

          В предыдущей статье мы разобрали реализацию двухпоточного bridge_server-а. На одном потоке асинхронно обрабатываются входящие HTTP-запросы посредством RESTinio. На втором потоке выполняются асинхронные запросы к delay_server-у посредством libcurl в виде curl_multi с использованием функций curl_multi_perform и curl_multi_wait.

          Сегодня же мы разберем другую реализацию bridge_server-а, которая асинхронно обслуживает и входящие, и исходящие HTTP-запросы на одном и том же пуле потоков. Из libcurl-а для этих целей применяется функция curl_multi_socket_action.

          Эта реализация заняла у нас больше всего времени. Давно не приходилось выкуривать столько бамбука, сколько довелось при разбирательстве с документацией к этой функции и примерами ее использования. По началу все это вообще воспринималось как какая-то черная магия, но потом свет в конце туннеля все-таки забрезжил, а код — заработал. Как именно заработал? А вот об этом сегодня и поговорим.
          Читать дальше →
          • +14
          • 1,8k
          • 7
        • Асинхронные HTTP-запросы на C++: входящие через RESTinio, исходящие через libcurl. Часть 2

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

            Несколько слов о том, как можно использовать curl_multi


            Библиотека libcurl широко известна в мире C и C++. Но, вероятно, наиболее широко она известна в виде т.н. curl_easy. Использовать curl_easy просто: сперва вызываем curl_easy_init, затем несколько раз вызываем curl_easy_setopt, затем один раз curl_easy_perform. И, в общем-то, все.

            В контексте нашего рассказа с curl_easy плохо то, что это синхронный интерфейс. Т.е. каждый вызов curl_easy_perform блокирует вызвавшую его рабочую нить до завершения выполнения запроса. Что нам категорически не подходит, т.к. мы не хотим блокировать свои рабочие нити на то время, пока медленный сторонний сервер соизволит нам ответить. От libcurl-а нам нужна асинхронная работа с HTTP-запросами.

            И libcurl позволяет работать с HTTP-запросами асинхронно через т.н. curl_multi. При использовании curl_multi программист все так же вызывает curl_easy_init и curl_easy_setopt для подготовки каждого своего HTTP-запроса. Но не делает вызов curl_easy_perform. Вместо этого пользователь создает экземпляр curl_multi через вызов curl_multi_init. Затем добавляет в этот curl_multi-экземпляр подготовленные curl_easy-экземпляры через curl_multi_add_handle и…
            Читать дальше →
            • +16
            • 2,1k
            • 6
          • Асинхронные HTTP-запросы на C++: входящие через RESTinio, исходящие через libcurl. Часть 1

              Преамбула


              Наша команда занимается разработкой небольшого, удобного в использовании, встраиваемого, асинхронного HTTP-сервера для современного C++ под названием RESTinio. Начали его делать потому, что нужна была именно асинхронная обработка входящих HTTP-запросов, а ничего готового, чтобы нам понравилось, не нашлось. Как показывает жизнь, асинхронная обработка HTTP-запросов в C++ приложениях нужна не только нам. Давеча на связь вышли разработчики из одной компании с вопросом о том, можно ли как-то подружить асинхронную обработку входящих запросов в RESTinio с выдачей асинхронных исходящих запросов посредством libcurl.

              По мере выяснения ситуации мы обнаружили, что эта компания столкнулась с условиями, с которыми сталкивались и мы сами, и из-за которых мы и занялись разработкой RESTinio. Суть в том, что написанное на C++ приложение принимает входящий HTTP-запрос. В процессе обработки запроса приложению нужно обратиться к стороннему серверу. Этот сервер может отвечать довольно долго. Скажем, 10 секунд (хотя 10 секунд — это еще хорошо). Если делать синхронный запрос к стороннему серверу, то блокируется рабочая нить, на которой выполняется HTTP-запрос. А это начинает ограничивать количество параллельных запросов, которые может обслуживать приложение.
              Читать дальше →
            • Задействовать для простых тестов наследование, полиморфизм и шаблоны? Почему бы и нет…

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

                Добавлю еще, что одним из мощных стимулов к написанию данной статьи стало то, что очень часто на глаза попадаются объемные флеймыобсуждения на тему «ООП не нужно» и, особенно, «шаблоны-дженерики на практике почти никогда не нужны». Мне, как далеко не молодому программисту, начинавшему в 1990-ом как раз с инструментов, в которых не было ни ООП, ни шаблонов-дженериков, странно сталкиваться с подобными точками зрения. Но, чем дальше, тем чаще с ними сталкиваешься. Особенно со стороны приверженцев новых языков программирования, вроде Go или Rust-а.

                Сложно сказать, чем это вызвано. Может быть людей перекормили ООП (а это так и было)… Может быть задачи за несколько минувших десятилетий сильно поменялись (а это так и есть)… Может быть и просто «вот и выросло поколение»… Как бы то ни было, можно попробовать на примере из реальной жизни показать, что все не так однозначно ©.

                Итак, о чем пойдет речь?
                Читать дальше →
              • Научиться перехватывать необработанные сообщения или пример того, как SObjectizer обрастает новыми фичами…

                  Нам очень приятно, когда в SObjectizer добавляются новые возможности, возникшие в результате подсказок и/или пожеланий пользователей SObjectizer-а. Хотя далеко не всегда это оказывается просто. Ведь, с одной стороны, у нас, как у команды разработчиков и старых пользователей SObjectizer-а, уже есть собственные стереотипы о том, как SObjectizer принято использовать. И не всегда получается сразу оценить «свежий взгляд со стороны», понять что реально хочет видеть пользователь во фреймворке и почему он не удовлетворен имеющимися средствами. С другой стороны, SObjectzer не такой уж и маленький фреймворк, добавление новых возможностей требует определенной осмотрительности. Нужно, чтобы новая функциональность не конфликтовала с уже имеющимися фичами. И, тем более, чтобы после добавления чего-то нового не сломалось то, что уже есть и давно работает. Плюс к тому, у нас есть пунктик по поводу сохранения совместимости между версиями SObjectizer-а, поэтому мы сильно против кардинальных изменений…

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

                  Под катом небольшой рассказ о том, как в SObjectizer добавлялась одна новая фича. Может быть кому-то из читателей будет интересно посмотреть, как старый фреймворк адаптируется под запросы новых пользователей.
                  Читать дальше →
                • Трехэтажные C++ные шаблоны в реализации встраиваемого асинхронного HTTP-сервера с человеческим лицом

                    Наша команда специализируется на C++ проектах. И нам время от времени приходилось создавать HTTP-точки входа в C++ компоненты. Для чего использовались разные инструменты. Тут были и старые-добрые CGI, и различные встраиваемые библиотеки, как сторонние, так и самописные. Все это работало, но всегда оставалось ощущение, что следовало бы делать такие вещи и проще, и быстрее, и производительнее.

                    В итоге мы решили, что пора прекращать смотреть по сторонам и нужно попробовать сделать что-то свое, с преферансом и куртизанками кроссплатформенностью, асинхронностью, производительностью и человеческим отношением к конечному пользователю. В результате у нас получилась небольшая C++14 библиотека RESTinio, которая позволяет запустить HTTP-сервер внутри C++ приложения всего несколькими строчками кода. Вот, например, простейший сервер, который на все запросы отвечает «Hello, World»:

                    #include <restinio/all.hpp>
                    
                    int main()
                    {
                       restinio::run(
                          restinio::on_this_thread()
                             .port(8080)
                             .address("localhost")
                             .request_handler([](auto req) {
                                return req->create_response().set_body("Hello, World!").done();
                             }));
                    
                       return 0;
                    }

                    В реализации RESTinio активно используются C++ные шаблоны и об этом хотелось бы сегодня немного поговорить.
                    Читать дальше →
                  • Почтовые ящики, которые и не ящики вовсе…

                      Когда летом 2016-го года создавалась первая статья про SObjectizer мы говорили, что со временем будем рассказывать и о деталях его реализации, дабы заинтересованные читатели могли заглянуть «под капот». Сегодняшняя статья будет как раз про потроха SObjectizer-а. Про механизм mbox-ов («почтовых ящиков»), который используется для организации взаимодействия акторов (агентов в нашей терминологии).

                      Почему речь именно про mbox-ы?


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

                      Зачем нужны mbox-ы?


                      Почтовые ящики в SObjectizer нужны для того, чтобы организовывать взаимодействие между агентами. Общение между агентами строится посредством асинхронных сообщений и эти самые сообщения нужно куда-то отсылать. Возникает вопрос: «Куда именно?»
                      Читать дальше →
                    • Actors for fun and profit

                        Эта статья является адаптированным вариантом текста одноименного доклада с конференции C++ CoreHard Autumn 2017. Статья рассматривается как завершение темы, поднятой ранее в публикациях "Модель Акторов и C++: что, зачем и как?" и «Шишки, набитые за 15 лет использования акторов в C++» часть I и часть II. Сегодня речь пойдет о том, как понять, что Модель Акторов может быть успешно использована в вашем проекте.


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


                        Лирическое отступление на тему «Модель Акторов и C++: миф или реальность?»


                        В статье обсуждаются вещи, которые присущи самой Модели Акторов, безотносительно конкретных языков программирования. Но, т.к. автор тесно связан с разработкой ПО на C++, то есть некоторый акцент на применимость акторов именно в C++.


                        Читать дальше →