Я работаю над встроенным решением, в котором работают два приложения: один - это пользовательский интерфейс, а другой работает в фоновом режиме, предоставляя данные для пользовательского интерфейса.
Недавно я столкнулся с утечкой памяти или аналогичной ошибкой, которая заставляет Linux убивать вторичный процесс, оставляя пользовательский интерфейс в остановленной ситуации, не сообщая ничего о том, что происходит. Я достиг этой проблемы, прочитав файл журнала message
Linux и распечатку программного обеспечения на терминале "Kill -myapp".
Мой вопрос: как я мог заметить такое событие (и другое подобное), поступающее из вторичного программного обеспечения, чтобы я мог правильно сообщить об этом пользователю и зарегистрировать его? Я имею в виду, что легко увидеть время в дереве процесса, чтобы узнать, работает ли вторичное приложение, и если это не так, сообщите "какое-то событие" в пользовательском интерфейсе, а также правдоподобно иметь ошибку -средняя система внутри вторичного приложения, которая заставляет его записывать в файл журнала, что только что произошло, и заставить пользовательский интерфейс время от времени читать этот файл для новых записей, но как может приложение UI узнать с более подробной информацией о том, что происходит в таких более резкие события? (в данном случае "Linux убил процесс", но это может быть "сегментный канал" или любой другой) (и если есть другое, лучшее решение, которое эта "постоянная читает файл журнала, созданный вторичным приложением", ld также хотел бы знать)
Примечания: пользовательский интерфейс написан на C++/Qt, а вторичное приложение - на C. Хотя решение с использованием библиотеки Qt будет приветствоваться, я думаю, что было бы лучше для всего сообщества разработчиков, если бы было предоставлено более обобщенное решение.
Вы можете создать обработчик сигналов для сигналов POSIX, таких как SIGKILL
в бэкэнд-процессе и уведомить ui, например, с помощью другого сигнала с сигексом. Любой механизм IPC должен работать, если он безопасен. Подробнее о сигналах: учебник и руководство
Иногда может быть хорошей проверкой на стороне ui периодически, потому что обработчик может не получиться.
Что касается лучшего способа проверить, жив ли процесс по сравнению с чтением файла журнала: проверьте, существует ли процесс с учетом его pid