Андрей Робачевский - Операционная система UNIX
- Название:Операционная система UNIX
- Автор:
- Жанр:
- Издательство:BHV - Санкт-Петербург
- Год:1997
- Город:Санкт-Петербург
- ISBN:5-7791-0057-8
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Андрей Робачевский - Операционная система UNIX краткое содержание
Книга посвящена семейству операционных систем UNIX и содержит информацию о принципах организации, идеологии и архитектуре, объединяющих различные версии этой операционной системы.
В книге рассматриваются: архитектура ядра UNIX (подсистемы ввода/вывода, управления памятью и процессами, а также файловая подсистема), программный интерфейс UNIX (системные вызовы и основные библиотечные функции), пользовательская среда (командный интерпретатор shell, основные команды и утилиты) и сетевая поддержка в UNIX (протоколов семейства TCP/IP, архитектура сетевой подсистемы, программные интерфейсы сокетов и TLI).
Для широкого круга пользователей
Операционная система UNIX - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
□ идентификаторы пользователя и группы,
□ переменные окружения,
□ диспозицию сигналов и их обработчики,
□ ограничения, накладываемые на процесс,
□ текущий и корневой каталог,
□ маску создания файлов,
□ все файловые дескрипторы, включая файловые указатели,
□ управляющий терминал.
Более того, виртуальная память дочернего процесса не отличается от образа родительского: такие же сегменты кода, данных, стека, разделяемой памяти и т.д. После возврата из вызова 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
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
#include
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
может быть проанализировано с помощью следующих макроопределений:
Интервал:
Закладка: