Портовые системы ручной работы в libcaf
В настоящее время у меня есть приложение, которое использует актеров ручной работы. Мой план состоит в том, чтобы портировать его на libcaf.
Текущее состояние:
У меня есть одна большая глобальная очередь сообщений, где мои системы (или актеры) подписываются на получение своих сообщений. Они отвечают сообщениями в эту глобальную очередь.
Вся система представляет собой приложение реального времени, которое работает на ядре Linux rt-preempt. Поток GUI сам по себе является системой (действующим лицом), но не имеет приоритета RT.
Прямо сейчас моим системам не нужно знать получателей их сообщений, потому что получатели регистрируются для своих желаемых.
Моя идея переноса заключается в следующем: я использую один глобальный актер в качестве замены моей глобальной очереди сообщений, и он обрабатывает регистрацию сообщений. Таким образом, я могу получить легкий журнал сообщений для целей отладки, и мне не нужно, чтобы все участники знали все возможные цели.
У меня есть система ввода-вывода (canbus), которая обрабатывает контакт с реальным миром.
В моей нынешней системе я создал поток GUI + система. Он ожидает инициализации RT. После создания потока графического интерфейса я переключаюсь на приоритет RT Preempt и создаю другие системы, предварительно устанавливаю стек и так далее. Когда все настроено, я уведомляю графический интерфейс, что RT работает. Теперь моя система инициализирована.
Когда происходит что-то фатальное или система должна завершить работу, я отправляю сообщение, и все системы закрываются, и все потоки объединяются.
Мои вопросы:
Как я могу отделить актер / поток GUI от потока RT в libcaf?
Вы бы порекомендовали раскошелиться GUI в отдельный процесс?
Могу ли я порождать актеров в разных приоритетных темах RT?
РЕДАКТИРОВАТЬ: я нахожу spawn вариант detached, Находятся ли порожденные актеры (дети отдельного актера) в одной и той же цепочке?
Решение
Текущее состояние: у меня есть одна большая глобальная очередь сообщений, где мои системы (или актеры) подписываются на получение своих сообщений. Они отвечают сообщениями в эту глобальную очередь.
Прямо сейчас моим системам не нужно знать получателей их сообщений, потому что получатели регистрируются для своих желаемых.
У CAF есть группы публикации / подписки, которые кажутся здесь подходящими. Потребители просто присоединяются к известной группе, а производители — к ней. Это дает вам именно ту связь между отправителями и получателями, которую вы ищете.
Когда происходит что-то фатальное или система должна завершить работу, я отправляю сообщение, и все системы закрываются, и все потоки объединяются.
Есть два способа легко достичь этого. Одним из них является использование группы, но для этого необходимо, чтобы все ваши участники были подписаны на нее при обнаружении фатального состояния системы. В качестве альтернативы, вы можете использовать один «корневой» актер, чтобы порождать всех других актеров и всегда использовать linked флаг во время спавна. Таким образом, убийство корневого субъекта рекурсивно убьет его потомков.
Как я могу отделить актер / поток GUI от потока RT в libcaf? Вы бы порекомендовали раскошелиться GUI в отдельный процесс?
В версии 0.14 вам придется переместить графический интерфейс в собственный процесс, а затем подключиться к нему через remote_actor, Как побочный эффект, это отделяет GUI от логики приложения и сбои в GUI не влияют на другие части вашей системы. Конечно, вы платите за связь и сериализацию на локальном хосте в этом сценарии.
С предстоящим 0.15 вы также можете использовать разные actor_system экземпляры с разделенными планировщиками. Это может сэкономить немного накладных расходов, но я все же предпочел бы переместить графический интерфейс в свой собственный процесс.
Кстати, вам не нужно на самом деле использовать fork, Вы можете просто запустить свое приложение, publish один актер к порту, а затем подключите свой графический интерфейс через remote_actor,
Я нахожу опцию возрождения отключенной. Находятся ли порожденные актеры (дети отдельного актера) в одной и той же цепочке?
Отдельный актер всегда будет работать в своем собственном потоке.
Могу ли я порождать актеров в разных приоритетных темах RT?
Краткий ответ: нет. CAF использует std::thread интерфейс, который является переносимым, но просто не поддерживает приоритеты RT. Добавление флагов приоритета при отсоединении акторов выполнимо, но таких специфических для платформы функций, как эта, в нашем списке задач нет.
При этом мы, конечно, принимаем исправления для CAF, которые добавляют поддержку приоритетов RT.
Другие решения
Других решений пока нет …