Реализация функциональности: разделение процессов или потоков?
Я работаю над приложением (C ++ в сочетании с Qt для графической части), которое будет работать на встроенной платформе Linux. Мне нужно знать, как разделить приложение на разные «ядра», каждое из которых заботится о другой части приложения, таким образом, чтобы улучшить стабильность, эффективность и безопасность самого приложения.
Я сомневаюсь: удобнее ли разделять функции на потоки или разбивать разные процессы?
Позвольте мне предоставить функциональное представление о приложении: существуют различные пользовательские интерфейсы, каждый из которых позволяет пользователям делать более или менее одинаковые вещи (не обращайте внимания на согласованность данных, я уже решил эту проблему). Каждый из этих интерфейсов должен действовать как отдельный (как разные терминалы одной и той же системы). Я хочу, чтобы все они отправляли и получали сообщения из одного и того же «ядра», которое будет заботиться об обновлении данных приложения или делать другие необходимые вещи.
Как лучше всего реализовать разделение между внутренним «ядром» и пользовательским интерфейсом?
Конечно, мне не хватает некоторых знаний, но до сих пор я придумал две альтернативы:
1 — разветвить «ядро» ребенка от отца и позволить ребенку выполнить определенную программу пользовательского интерфейса (у меня нет практического опыта в этом вопросе, так как в этом случае я могу заставить отца и ребенка общаться (учитывая, что ребенок новый процесс)?)
2 — создавать разные потоки для каждого ядра и пользовательского интерфейса.
Мне нужно это разделение, потому что приложение должно быть максимально стабильным и способным перезапускать пользовательский интерфейс в случае сбоя. Имейте также в виду, что у всего приложения не будет бесконечной памяти и доступных ресурсов.
Заранее спасибо за вашу помощь, привет.
Решение
Существует несколько причин, по которым переход на отдельный маршрут процесса может быть хорошим выбором во встроенной системе:
-
Разделение компонентов: запуск компонентов в качестве отдельных процессов является окончательным разделением. Часто полезно, когда проекты становятся очень большими
-
Управление безопасностью и привилегиями. Вполне вероятно, что во встроенной системе некоторые компоненты нуждаются в повышенных привилегиях для управления устройствами, тогда как другие представляют потенциальную угрозу безопасности (например, компоненты, обращенные к сети), которые вы хотите запускать с минимально возможными привилегиями. Другими вероятными сценариями являются компоненты, которые требуют многопоточности в реальном времени или чтобы иметь возможность
mmap()много системной памяти. Перераспределение любого из них заблокирует вашу систему так, что она не сможет восстановиться. -
Надежно: Вы можете потенциально возродить части системы, если они потерпят неудачу, оставив оставшуюся работу
Построение такого соглашения на самом деле проще, чем предлагают другие — Qt действительно хорошо поддерживает DBus — который хорошо заботится о вашем IPC и широко используется в настольных системах Linux для функций управления системой.
Что касается описанного вами сценария, вы можете захотеть демонизировать «ядро» приложения и затем разрешить клиентские соединения через dbus из компонентов пользовательского интерфейса.
Другие решения
Запуск пользовательского интерфейса в другом потоке не даст вам дополнительной стабильности — другой поток может уничтожить кучу движка, и даже если вы прервете поток, любые ресурсы, которые у него есть, не будут использованы повторно.
Вы можете немного улучшить стабильность, имея действительно прочную стену абстракции между Engine и UI. Так что это не совсем бесполезно.
Множество процессов требуют большого количества скачков — вам нужен метод IPC (межпроцессное взаимодействие).
Обратите внимание, что IPC и в меньшей степени стены абстракции могут добавить к накладным расходам вашей программы.
Важный вопрос, который нужно задать: «сколько данных должно пройти между пользовательским интерфейсом и механизмом?» — если данных недостаточно (например, «запустить задачу» из пользовательского интерфейса в движок и «эта задача выполнена на 50%» из движка в пользовательский интерфейс), IPC не доставляет хлопот. Если вы используете интерактивное приложение для рисования с полноэкранными обновлениями изображения в реальном времени, IPC будет более раздражающим и менее практичным.
Теперь быстрый гугл по Qt и IPC говорит мне, что для встроенного Linux есть расширение Qt, которое позволяет сигналам и слотам Qt передавать сообщения между процессами: Qt COmmunications Protocol (QCOP). Одна проблема, с которой я столкнулся при работе с подобными инфраструктурами, заключается в том, что она может легко привести к запутыванию между состоянием клиента и сервера, что может поставить под угрозу стабильность на другом конце канала связи по сравнению с относительно простыми протоколами.
detector