Жизненный цикл процесса

Управляющий терминал

Приоритет и значение nice

Реальный (GID) и эффективный (EGID) идентификаторы группы

GID – это реальный идентификатор группы, равный идентификатору GID его родительского процесса.

Эффективный идентификатор группы EGID аналогичен по своему предназначению эффективному идентификатору пользователя. Когда процесс, например, обратиться к файлу, на который не имеет прав владельца, ядро автоматически проверит, можно ли предоставить доступ к файлу на основании данного EGID.

От приоритета процесса зависит, какая часть времени будет выделена ему центральным процессором. Для выполнения ядро выбирает процесс с самым высоким “внутренним приоритетом”.

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

Большинство процессов имеют связанный с ними управляющий терминал. Этот терминал определяет компоновку по умолчанию стандартного файла (или канала) ввода, стандартного файла вывода и стандартного вывода ошибок. Когда пользователь вводит какую-либо команду из shell, его терминал, как правило, становится управляющим терминалом процесса.

Процессы не появляются в системе по волшебству и не создаются спонтанно ядром. Новые процессы порождаются другими процессами, как и человеческие существа (мы подразумеваем, что человеческие существа порождаются человеческими существами, а не UNIX-процессами).

Для создания нового процесса его будущий родитель копирует самого себя с помошью системного вызова fork. Новый процесс является точной копией породившего его процесса. И что самое интересное – новый процесс имеет те же инструкции и данные, что и у его родителя, при этом выполнение родительского и порожденного процесса начинает с одной и той же инструкции, следующей за вызовом fork.

Отличия порожденного процесса и его родителя заключаются в следующем:

· у нового процесса свой PID;

· PPID нового процесса равен PID родителя;

· учетная информация нового процесса обнулена;

· у нового процесса имеется свой собственный экземпляр дескрипторов файлов.

Системный вызов fork имеет уникальное свойство: он возвращает сразу два значения. С точки зрения порожденного процесса это значение равно нулю, а с точки зрения родительского процесса это значение не что иное, как PID порожденного им процесса. Именно по этим значениям два процесса могут различить друг друга.

После выполнения вызова fork чтобы запустить новую программу процесс выполняет один из системных вызовов семейства exec.

Все вызовы семейства exec выполняют приблизительно одни и те же функции: они замещают текст программы, которую выполняет процесс кодом новой программы, которая должна быть выполнена и устанавливают сегменты данных и стека в исходное состояние. Когда вызывается одна из подпрограмм exec, она записывает в адресное пространство процесса содержимое нового програмного файла, а затем возобновляет выполнение с означенной точки входа нового текста. Формы вызова exec различаются только способами указания аргументов командной строки и среды, передаваемой новому процессу. Создание процессов путем системного вызова fork, а затем замещение кода вновь созданного процесса на необходимый часто называется схемой fork-and-exec.

В качестве примера рассмотрим вызов команды ls из командного интерпретатора shell: текущий процесс (shell) делает вызов fork, что приводит к порождению вторую копию shell. Далее порожденный shell вызывает exec, указывая в качестве параметра имя исполняемого файла, образ которого необходимо загрузить в память вместо кода порожденного shell. В нашем случае это код программы ls. Затем программа ls замещает код порожденного shell и начинает выполняться. После того, как программа завершила свое выполнение созданный процесс “умирает”.

Когда операционная система загружается, ядро самостоятельно создает несколько процессов. Самый важный из них – процесс init. PID этого процесса всегда равен 1. Все последующие после загрузки системы процессы, кроме тех, которые создаются ядром, являются потомками init.

Процесс init играет важную роль и в управлении процессами. Когда процесс завершается, он вызывает подпрограмму _exit, чтобы уведомить ядро системы о готовности “умереть”. В качестве параметва подпрограмме _exit передаются целое число, указывающее на причину завершения процесса и называемое кодом завершения. По соглашению нулевой код завершения процесса указывает на его “успешное” выполнение.

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

Этот механизм работает нормально, если родительский процесс завершается после своих потомков и добросовестно вызывает wait для того, чтобы все порожденные им процессы, находящиеся в состоянии “зомби” умерли. Если же родительский процесс “умирает» первым, что ядро понимает, что вызова wait не последует и дарит всех зомби процессу init. Процесс init обязан принять всех переданных ему зомби и выполнить вызов wait, необходимый для их ликвидации. Иногда (весьма редко и не во всех системах) процесс init не выполняет вызов wait, и зомби остаются в системе. Однако никаких проблем они при этом не создают.

Дата добавления: 2014-12-07