Операционная система UNIX - Андрей Робачевский
Шрифт:
Интервал:
Закладка:
Создание и управление процессами
Работая в командной строке shell вы, возможно, не задумывались, каким образом запускаются программы. На самом деле каждый раз порождается новый процесс, а затем загружается программа. В UNIX эти два этапа четко разделены. Соответственно система предоставляет два различных системных вызова: один для создания процесса, а другой для запуска новой программы.
Новый процесс порождается с помощью системного вызова fork(2):
#include <sys/types.h>
#include <unistd.h>
pid_t fork(void);
Порожденный, или дочерний процесс, хотя это кажется странным, является точной копией процесса, выполнившего этот вызов, или родительского процесса. В частности, дочерний процесс наследует такие атрибуты родителя, как:
□ идентификаторы пользователя и группы,
□ переменные окружения,
□ диспозицию сигналов и их обработчики,
□ ограничения, накладываемые на процесс,
□ текущий и корневой каталог,
□ маску создания файлов,
□ все файловые дескрипторы, включая файловые указатели,
□ управляющий терминал.
Более того, виртуальная память дочернего процесса не отличается от образа родительского: такие же сегменты кода, данных, стека, разделяемой памяти и т.д. После возврата из вызова fork(2), который происходит и в родительский и в дочерний процессы, оба начинают выполнять одну и ту же инструкцию.
Легче перечислить немногочисленные различия между этими процессами, а именно:
□ дочернему процессу присваивается уникальный идентификатор PID.
□ идентификаторы родительского процесса PPID у этих процессов различны,
□ дочерний процесс свободен от сигналов, ожидающих доставки,
□ значение, возвращаемое системным вызовом fork(2) различно для родителя и потомка.
Последнее замечание требует объяснения. Как уже говорилось, возврат из функции fork(2) происходит как в родительский, так и в дочерний процесс. При этом возвращаемое родителю значение равно PID дочернего процесса, а дочерний, в свою очередь, получает значение, равное 0. Если fork(2) возвращает -1, то это свидетельствует об ошибке (естественно, в этом случае возврат происходит только в процесс, выполнивший системный вызов).
В возвращаемом fork(2) значении заложен большой смысл, поскольку оно позволяет определить, кто является родителем, а кто — потомком, и соответственно разделить функциональность. Поясним это на примере:
main() {
int pid;
pid = fork();
if (pid == -1) {
perror("fork");
exit(1);
}
if (pid == 0) {
/* Эта часть кода выполняется дочерним процессом */
printf("Потомокn");
} else {
/* Эта часть кода выполняется родительским процессом */
printf("Родительn");
}
}
Таким образом, порождение нового процесса уже не кажется абсолютно бессмысленным, поскольку родитель и потомок могут параллельно выполнять различные функции. В данном случае, это вывод на терминал различных сообщений, однако можно представить себе и более сложные приложения. В частности, большинство серверов, одновременно обслуживающих несколько запросов, организованы именно таким образом: при поступлении запроса порождается процесс, который и выполняет необходимую обработку. Родительский процесс является своего рода супервизором, принимающим запросы и распределяющим их выполнение. Очевидным недостатком такого подхода является то, что вся функциональность по-прежнему заложена в одном исполняемом файле и, таким образом, ограничена.
UNIX предлагает системный вызов, предназначенный исключительно для запуска программ, т.е. загрузки другого исполняемого файла. Это системный вызов exec(2), представленный на программном уровне несколькими модификациями:
#include <unistd.h>
int execl(const char *path, const char *arg0, ... ,
const char *argn, char * /* NULL */);
int execv(const char* path, char* const argv[]);
int execle(const char *path, char *const arg0[], ... ,
const char *argn, char* /* NULL */, char *const envp[]);
int execve(const char* path, char const argv[],
char *const envp[]);
int execlp(const char *file, const char *arg0, ... ,
const char* argn, char * /* NULL */);
int execvp(const char *file, char *const argv[]);
Все эти функции по существу являются надстройками системного вызова execve(2), который в качестве аргументов получает имя запускаемой программы (исполняемого файла), набор аргументов и список переменных окружения. После выполнения execve(2) не создается новый процесс, а образ существующего полностью заменяется на образ, полученный из указанного исполняемого файла. На рис. 2.12 показано, как связаны между собой приведенные выше функции.
Рис. 2.12. Семейство функций exec(2)
В отличие от вызова fork(2), новая программа наследует меньше атрибутов. В частности, наследуются:
□ идентификаторы процесса PID и PPID,
□ идентификаторы пользователя и группы,
□ эффективные идентификаторы пользователя и группы (в случае, если для исполняемого файла не установлен флаг SUID или SGID),
□ ограничения, накладываемые на процесс,
□ текущий и корневой каталоги,
□ маска создания файлов,
□ управляющий терминал,
□ файловые дескрипторы, для которых не установлен флаг FD_CLOEXEC.
Наследование характеристик процесса играет существенную роль в работе операционной системы. Так наследование идентификаторов владельцев процесса гарантирует преемственность привилегий и, таким образом, неизменность привилегий пользователя при работе в UNIX. Наследование файловых дескрипторов позволяет установить направления ввода/вывода для нового процесса или новой программы. Именно так действует командный интерпретатор. Мы вернемся к вопросу о наследовании в главе 3.
В главе 1 уже говорилось о частом объединении вызовов fork(2) и exec(2), получившем специальное название fork-and-exec. Таким образом загружается подавляющее большинство программ, которые выполняются в системе.
При порождении процесса, который впоследствии может загрузить новую программу, "родителю" может быть небезынтересно узнать о завершении выполнения "потомка". Например, после того как запущена утилита ls(1), командный интерпретатор приостанавливает свое выполнение до завершения работы утилиты и только после этого выдает свое приглашение на экран. Можно привести еще множество ситуаций, когда процессам необходимо синхронизировать свое выполнение с выполнением других процессов. Одним из способов такой синхронизации является обработка родителем сигнала SIGCHLD, отправляемого ему при "смерти" потомка. Механизм сигналов мы рассмотрим в следующем разделе. Сейчас же остановимся на другом подходе.
Операционная система предоставляет процессу ряд функций, позволяющих ему контролировать выполнение потомков. Это функции wait(2), waitid(2) и waitpid(2):
#include <sys/types.h>
#include <sys/wait.h>
pid_t wait(int* stat_loc);
int waitpid(idtype_t idtype, id_t id,
siginfo_t * infop, int options);
pid_t waitpid(pid_t pid, int *stat_loc, int options);
Первый из этих вызовов wait(2) обладает самой ограниченной функциональностью — он позволяет заблокировать выполнение процесса, пока кто-либо из его непосредственных потомков не прекратит существование. Вызов wait(2) немедленно возвратит состояние уже завершившегося дочернего процесса в переменной stat_loc, если последний находится в состоянии зомби. Значение stat_loc может быть проанализировано с помощью следующих макроопределений:
WIFEXITED(status) Возвращает истинное (ненулевое) значение, если процесс завершился нормально. WEXITSTATUS(status) Если WIFEXITED(status) не равно нулю, определяет код возврата завершившегося процесса (аргумент функции exit(2)). WIFSIGNALLED(status) Возвращает истину, если процесс завершился по сигналу. WTERMSIG(status) Если WIFSIGNALLED(status) не равно нулю, определяет номер сигнала, вызвавшего завершение выполнения процесса. WCOREDUMP(status) Если WIFSIGNALLED(status) не равно нулю, макрос возвращает истину в случае создания файла core.Системный вызов waitid(2) предоставляет больше возможностей для контроля дочернего процесса. Аргументы idtype и id определяют, за какими из дочерних процессов требуется следить:
