Зачем нужна иерархия процессов в Unix?

Question

[cypok]

В данный момент читаю книгу Эндрю Таненбаума «Современные операционные системы».



Не совсем понятно, зачем же в Unix поддерживается иерархия процессов? Таненбаум пишет следующее, но мне все-равно не понятна их роль:

В UNIX процесс, все его дочерние процессы и более отдаленные потомки образуют группу процессов. Когда пользователь отправляет сигнал с клавиатуры, тот достигает всех участников этой группы процессов, связанных на тот момент времени с клавиатурой (обычно это все действующие процессы, которые были созданы в текущем окне). Каждый процесс по отдельности может захватить сигнал, игнорировать его или совершить действие по умолчанию, которое должно быть уничтожено сигналом.



В качестве другого примера, поясняющего ту роль, которую играет иерархия процессов, давайте рассмотрим, как UNIX инициализирует саму себя при запуске. В загрузочном образе присутствует специальный процесс, называемый init В начале своей работы он считывает файл, сообщающий о количестве терминалов. Затем он разветвляется, порождая по одному процессу на каждый терминал. Эти процессы ждут, пока кто-нибудь не зарегистрируется в системе. Если регистрация проходит успешно, процесс регистрации порождает оболочку для приема команд. Эти команды могут породить другие процессы, и т. д. Таким образом, все процессы во всей системе принадлежат единому дереву, в корне которого находится процесс init.

Если кто-то может популярно объяснить – буду очень признателен.

Answer 1

[Zigmar]

Я думаю тут не совсем корректен вопрос «зачем», я думаю это просто свойство, которое является прямым следствием архитектуры системы. Я не уверен, с какого конца шли проектировщики юникс, но мне кажется, что не от «давайте сделаем дерево процессов», а «как будем реализовывать создание и управление процессами». Дело в том, что в юникс, процессы, кроме init, не создаются просто так, «из воздуха», они всегда отпочковываются от другого процесса (fork) и в результате из одного процесса получаются два — родительский и дочерней между которыми есть тесная связь (и как следствие естественным образом получая древовидную структуру). Кроме уже упомянутых сигналов, дочерний процесс наследует дескрипторы файлов, через которые, если надо, налаживается связь между дочерним и родительским процессом.

Answer 2

[odessky]

Чтоб при убитии голвного автоматически закрылись все дочерние. А по graceful отмерли все дочерние, но остался головной. См апач например.

Comments

[cypok]

Однако при завершении процесса родителя, его дети не завершаются. Можете пояснить?

[odessky]

ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81-%D1%81%D0%B8%D1%80%D0%BE%D1%82%D0%B0

[MrSteve]

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

[odessky]

Все верно. В Unix — завершает.

Answer 3

[ksusha]

Просто в Unix'е очень многое завязано на иерархии процессов, что и демонстрируют приведенные в цитате примеры.

Вот еще примерчик, где используется иерархия.
Когда процесс умирает, его родитель оповещается об этом. После этого он (родитель) удаляет из таблицы дескриптор умершего дочернего процесса. Если у процесса нет родителя, то этот дескриптор без перезагрузки ОС из памяти уже не удалить. Это расходует память. Дескриптор процесса весит не так чтобы уж очень мало — ~ 1,7 Кб.

Если родитель умер раньше дочки, то родитель переназначается, часто это бывает как раз init, который периодически запрашивает информацию о своих потомках и убивает их дескрипторы.

Еще реализация потоков (в Линуксе по крайней мере, где нет явной поддержки потоков) завязана на связи процессов между собой. Когда дочка порождается родителем, с помощью флагов указывается какие ресурсы шарить между ними. Плюс ко всему дочерний процесс наследует от родительского очень много свойств, напирмер UID, таким образом процесс запускается с теми же привилегиями, что и родительский.

Если бы не было иерархии, все вышеперечисленное пришлось бы реализовывать как-то по-другому, но в Unix'e это так, просто особенность архитектуры, как Zigmar написал.

Answer 4

[MrSteve]

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

Answer 5

[Эльдар Мусин]

Смысл заключается именно в коммуникациях между процессами. Так как он и описывает, но я согласен, что он не говорит напрямую, для чего это нужно.
На самом деле, с помощью иерархии, есть возможность захватить все процессы, через init.
Если бы не существовало иерархии, то бродкаст системных сигналов мог не всех касаться.
Затем уже в самом процессе которые посылает, можно указать, на каком уровне его нужно слушать.