Портальные системы управления для libcaf

Question

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

Текущее состояние: У меня есть одна большая глобальная очередь сообщений, где мои системы (ака актеры) подписываются на получение своих сообщений. Они отвечают сообщениями на эту глобальную очередь.

Вся система - приложение реального времени, которое работает на ядре Linux rt-preempt. Поток GUI - это сама система (актер), но она не относится к приоритету RT.

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

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

У меня есть система ввода-вывода (canbus), которая управляет контактом с реальным миром.

В моей текущей системе я создаю нить + систему GUI. Он ждет инициализации RT. После генерации потока gui я переключаюсь на приоритет RT Preempt и создаю другие системы, префикс стека и так далее. Когда все настроено, я уведомляю gui о том, что RT вверх. Теперь моя система инициализирована.

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

Мои вопросы: Как я могу разделить актер/поток GUI от потока RT в libcaf? Вы бы рекомендовали развернуть графический интерфейс в отдельном процессе? Могу ли я создавать актеров на разных потоках приоритета RT?

EDIT: Я нахожу опцию spawndetached. Являются ли порожденные актеры (дети отдельного актера) в одной и той же теме?

Answer 1

Текущее состояние: У меня есть одна большая глобальная очередь сообщений, где мои системы (ака актеры) подписываются на получение своих сообщений. Они отвечают сообщениями на эту глобальную очередь.

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

CAF публикует/подписывает группы, которые, как представляется, подходят для этого. Потребители просто присоединяются к известной группе, и производители отправляют ее. Это дает вам именно развязку отправителей и получателей, которые вы ищете.

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

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

Как я могу разделить актер/поток GUI от потока RT в libcaf? Вы бы рекомендовали развернуть GUI в отдельном процессе?

В 0.14 вам нужно будет переместить графический интерфейс в свой собственный процесс, а затем подключиться к нему через remote_actor. В качестве побочного эффекта это отделяет GUI от логики приложения и сбои в графическом интерфейсе не влияют на другие части вашей системы. Конечно, вы платите за локальную связь и сериализацию в этом сценарии.

С предстоящим 0.15 вы также можете использовать разные экземпляры actor_system с отдельными планировщиками. Это может сэкономить немного накладных расходов, но я бы предпочел переместить графический интерфейс в собственный процесс.

Кстати, вам не нужно использовать fork. Вы можете просто запустить свое приложение, publish одного актера в порт, а затем подключить свой графический интерфейс через remote_actor.

Я нахожу опцию spawn отдельно. Являются ли порожденные актеры (дети отдельного актера) в одной и той же теме?

Отдельный актер всегда будет работать в своей собственной нити.

Могу ли я создавать актеры на разных потоках приоритета RT?

Короткий ответ: нет. CAF использует интерфейс std::thread, который переносимый, но просто не поддерживает приоритеты RT. Добавление флагов приоритета при отсоединении актеров выполнимо, но специфичные для платформы функции не входят в наш список задач.

Это, как говорится, мы, разумеется, принимаем патчи к CAF, которые добавляют поддержку приоритета RT.