Почему функция fork() должна возвращать файловый дескриптор?

Проблема описана там в вашем источнике, select()должен прерываться сигналами типа SIGCHLD, но в некоторых случаях это не так хорошо работает. Таким образом, обходным путем является запись сигнала в канал, за которым затем следит select(). select()предназначен для наблюдения за файловыми дескрипторами, так что это решает проблему.

Обходной путь по существу превращает событие сигнала в событие дескриптора файла. Если бы fork()просто вернул fd, обходной путь не потребовался бы, так как этот fd можно было бы использовать напрямую с select().

Так что да, ваше описание в последнем абзаце кажется мне правильным.

Еще одна причина, по которой fd (или какой-либо другой вид дескриптора ядра )лучше простого идентификатора процесса, заключается в том, что PID можно повторно использовать после того, как процесс умирает. Это может быть проблемой в некоторых случаях при отправке сигналов процессам, может быть невозможно точно знать, что это именно тот процесс, о котором вы думаете, а не другой, повторно использующий тот же PID. (Хотя я думаю, что это не должно быть проблемой при отправке сигналов дочернему процессу, так как родитель должен выполнить wait()для дочернего процесса, чтобы его PID был освобожден.)

Бернстайн не приводит большого контекста для этого замечания «Правильно», но рискну предположить, что :fork (2 )return PID несовместим с open (2 ), creat (2 )и т.д., возвращающие файловые дескрипторы. Остальная часть системы Unix могла выполнять манипуляции с процессами с файловым дескриптором, представляющим процесс, вместо PID. Существует системный вызов signalfd (2 ), который обеспечивает несколько лучшее взаимодействие между сигналами и файловыми дескрипторами и показывает, что файловый -дескриптор -, представляющий процесс, может работать.

Это просто размышление о том, что «было бы здорово, если бы Unix проектировался иначе, чем он есть».

Проблема с PID заключается в том, что они живут в глобальном пространстве имен, где их можно повторно использовать для другого процесса, и было бы неплохо, если бы fork()возвращал в родителя какой-то дескриптор, который гарантированно всегда будет ссылаться на процесс. дочерний процесс, и что он может передаваться другим процессам через наследование или unix-сокеты /SCM_RIGHTS[1].

См. также обсуждение здесь для недавней попытки «исправить» это в Linux, включая добавление флага в clone(), который заставит его возвращать pid -fd вместо PID.

Но даже в этом случае это не устранило бы необходимости во взломе -канала [2] или улучшенных интерфейсах, поскольку сигналы, уведомляющие родительский процесс о состоянии дочернего процесса, — не единственные, которые вы хотели бы использовать. дескриптор в основном цикле программы. К сожалению, такие вещи, как epoll(7) + signalfd(2)в Linux или kqueue(2)в BSD, не являются стандартными --единственный стандартный интерфейс (, но не поддерживаемый в более старых системах )намного хуже pselect(2).

[1] Предотвращение повторного -цикла PID к моменту возврата системного вызова waitpid()и использования его возвращаемого значения, вероятно, может быть достигнуто в более новых системах с использованием вместо этого waitid(.., WNOWAIT).

[2] Я бы не стал комментировать Д.Дж. Бернштейн утверждает, что это он изобрел (извините за апофазию; -)).

Дело в том, что существует множество программ, которые работают с моделью цикла событий -, основанной на мониторинге файловых дескрипторов с select (2)/ poll (2 ). / epoll (7). Но были различные события, которые исторически не уведомлялись с помощью файловых дескрипторов --, среди них переход состояния процесса (, например, завершение )дочернего процесса. Необходимость отдельной обработки этих других событий (, которые включают в себя истечение времени таймера, сигналы и события синхронизации, такие как изменения семафора ), усложняет программирование модели цикла событий -.

За последние несколько лет разработка Linux упростила решение этой проблемы, так что в настоящее время у нас есть signalfd (2)(сделать сигналы доступными для чтения из файлового дескриптора ), eventfd (2)(примитив синхронизации, дескриптор которого является файловым дескриптором ), и timerfd _создание (2)(создание таймеров, которые уведомляют через файловый дескриптор ), все которые создают файловые дескрипторы, которые можно передать в select (2)/ poll (2)/ epoll (7).

И, наконец, в последних версиях Linux добавлена ​​концепция дескриптора процесса в виде файлового дескриптора. Флаг CLONE_PIDFDдля clone3()может использоваться для создания дочернего процесса, для которого возвращается файловый дескриптор в качестве дескриптора. Дескриптор файла также может быть передан в select (2)/ poll (2)/ epoll (7)и указывается как читаемый, если дочерний процесс завершается.