Имеет ли родитель процесса какое-либо значение с точки зрения его потомка?
Если вы можете изменить драйвер, вы можете посмотреть мой ответ здесь .
Мое решение состоит в том, чтобы поместить usleep_range(1000000, 12000000);в функцию probe в вашем драйвере, чтобы драйвер задержался на 10 -12 секунд. Функция probe — это место, где драйвер начинает выполнение/инициализацию.
Когда я увидел этот вопрос, меня это очень заинтересовало, потому что я знаю, что я уже видел использование getppid... но не мог вспомнить, где именно. Итак, я обратился к одному из проектов, который, как я полагал, вероятно, использовал все системные вызовы Linux, а затем некоторые:systemd . Один поиск на GitHub позже, и я нашел два варианта использования, которые изображают некоторые более общие варианты использования (есть и несколько других вариантов использования, но они более специфичны для systemd):
В sd -уведомить . Для некоторого контекста :systemd необходимо знать, когда служба запущена, чтобы она могла приступить к запуску любой, которая от нее зависит. Обычно это делается из программы C через sd _notify API , который позволяет демонам сообщать systemd о своем статусе.
Конечно, если вы используете сценарий оболочки в качестве службы... вызов функций C не совсем осуществим. Таким образом, systemd поставляется с командой systemd -notify , которая представляет собой небольшую оболочку над API-интерфейсом sd _notify. Одна проблема :systemd также должен знать PID, который отправляет сообщение. Для systemd -notify это будет собственный PID, который будет короткоживущим идентификатором -процесса, который немедленно исчезнет. Не полезно.
Вы, наверное, уже знаете, к чему я клоню. :getppid используется systemd -notify для получения PID родительского процесса, так как обычно это реальный служебный процесс. Короче говоря, getppid может использоваться короткоживущим CLI-приложением -для отправки сообщения от имени родительского процесса.
Как только я нашел это, мне на ум пришел другой инструмент unix, который мог бы использовать getppid, :polkit, который представляет собой структуру аутентификации процессов, используемую для блокировки таких вещей, как отправка сообщений шины D -или запуск привилегированных приложений. (Как минимум, я полагаю, вы видели подсказки пароля графического интерфейса, которые отображаются агентами аутентификации polkit.)polkit включает исполняемый файл с именем
pkexec, который можно использовать как sudo, за исключением того, что теперь polkit используется для авторизации. Теперь polkit должен знать PID процесса, запрашивающего авторизацию... да, вы поняли, pkexec использует getppid, чтобы найти этот .(Глядя на это, я также обнаружил, что агент авторизации TTY polkit тоже использует его .)
Это немного менее интересно, но все же примечательно. :getppid используется для эмуляции PR _SET _PDEATHSIG , если родитель умер к моменту установки этого флага. (Флаг — это просто способ автоматической отправки дочернему элементу сигнала типа SIGKILL, если родитель умирает.)
Зомби:Это крайний случай, но он эффективен в том смысле, что влияет на то, останавливается программа или нет. Единственная ситуация, с которой я столкнулся, когда поведение дочернего процесса отличается в зависимости от того, какой процесс он является родителем, - это время его выхода. Когда процесс завершается, SIGCHLDотправляется в ppidдочернего процесса. Если родительский процесс застрял или не обрабатывает SIGCHLD, то дочерний процесс остается в состоянии зомби до тех пор, пока не будет получен его выходной сигнал. Если ppidдочернего процесса изменяется, когда он находится в состоянии зомби, путем уничтожения родительского процесса и повторного -порождения init, а SIGCHLDполучен, то дочерний процесс завершит завершение и будет пожинал.
Представляется, что ряд сценариев, в которых процессу требуется какая-либо осведомленность о любом другом процессе в системе, таком как его родитель, главный -родитель и т. д., включает в себя управление процессом и/или межпроцессный -процесс -. ] коммуникация. Чтобы еще больше сузить область, диапазон операций, которые принимают pid_tв качестве аргумента или возвращают pid_t, в основном включает в себя сигнализацию и другие задачи управления процессами. Учитывая такой ограниченный диапазон применений, единственными причинами, которые я могу придумать для использования getppid, помимо диагностической информации, было бы, если дочернему элементу необходимо сигнализировать родителю или определить, работает ли родитель. Например, mod_mdв Apachehttpdотправляет сигнал корректного перезапуска родительскому процессу , чтобы инициировать реконфигурацию.
Хотя «Примечание» к вашему вопросу описывает хорошую альтернативу getppid, оно также намекает на возможное использование для getppid. Для контекста, вчера вечером я смотрел презентацию PWL Conf 2019,О выразительности языков программирования и определение «выразительности» из этой статьи искажает мою интерпретацию вопроса. Определение сводится к тому, как поведение программы может отличаться с наличием функции или без нее.
Начиная с предположений:
- По какой-то причине процесс должен сигнализировать своему родительскому процессу.
- Разные операционные системы по-разному -обрабатывают осиротевшие процессы.
Что означает, если предварительный-forkPID не соответствует getppid? Сравнение прежнего-forkPID с getppidможет на самом деле предоставить кросс-платформенный -механизм, свободный от расы -для дочернего процесса, чтобы определить, был ли он осиротевшим. Если pre-fork-pid != getppidто ребенок осиротел, иначе нет.
Это кажется необычным, или что-то, что, вероятно, будет написано с использованием компиляции для конкретной платформы, #ifdef, когда это необходимо. Кроме того, аналогичный эффект может быть достигнут с использованием kill 0на пре--fork-pid, однако это может привести к ложным срабатываниям в достаточно долго выполняющихся процессах, когда система повторно использует «старые» идентификаторы процессов.
Таким образом, комбинация неизменяемого идентификатора родительского процесса до-forkи «живого» getppidвызова выглядит как высоконадежный межплатформенный -механизм для проверки или сигнализации родительского процесса..