Арнольд Роббинс - Linux программирование в примерах

• Название: Linux программирование в примерах
• Автор: Арнольд Роббинс
• Издательство: Кудиц-Образ
• Жанр: Программное обеспечение
• Год: 2005
• ISBN: 5-9579-0059-1

В книге рассмотрены вопросы, связанные с программированием под Linux: файловый ввод/вывод, метаданные файлов, основы управления памятью, процессы и сигналы, пользователи и группы, вопросы интернационализации и локализации, сортировка, поиск и многие другие. Много внимания уделено средствам отладки, доступным под GNU Linux. Все темы иллюстрируются примерами кода, взятого из V7 UNIX и GNU. Эта книга может быть полезна любому, кто интересуется программированием под Linux.

---

В BSD 4.2 и 4.3 аргумент status функций wait() и wait3() был union wait. Он умещался в int и предоставлял доступ к тем же сведениям, которые выдают современные макросы WIFEXITED() и др., но через членов объединения. Не все члены были действительными во всех случаях. Эти члены и их использование описаны в табл. 9.3.

Таблица 9.3. union wait 4.2 и 4.3 BSD

Макрос POSIX Член объединения Использование Значение WIFEXITED() w_termsig w.w_termsig == 0 True при нормальном завершении WEXITSTATUS() w_retcode code = w.w_retcode Статус завершения, если не по сигналу WIFSIGNALED() w_termsig w.w_temsig != 0 True, если завершен по сигналу WTERMSIG() w_termsig sig = w.w_termsig Сигнал, вызвавший завершение WIFSTOPPED() w_stopval w.w_stopval == WSTOPPED True, если остановлен WSTOPSIG() w_stopsig sig = w.w_stopsig Сигнал, вызвавший остановку WCOREDUMP() w_coredump w.w_coredump != 0 True, если потомок сделал снимок образа

POSIX не стандартизует union wait, a BSD 4.4 не документирует его, используя вместо этого макросы POSIX. GLIBC делает несколько бросков, чтобы заставить использующий его старый код продолжать работать. Мы опишем его здесь главным образом для того, чтобы вы увидев его — узнали; новый код должен использовать макросы, описанные в разделе 9.1.6.1 «Использование функций POSIX: wait() и waitpid()».

9.2. Группы процессов

Группа процесса является группой связанных процессов, которые в целях управления заданием (job) рассматриваются вместе. Процессы с одним и тем же ID группы процессов являются членами группы процессов, а процесс, PID которого равен ID группы процессов, является лидеров группы процессов. Новые процессы наследуют ID группы процессов своих родительских процессов.

Мы уже видели, что waitpid() позволяет вам ждать любой процесс в данной группе процессов. В разделе 10.6.7 «Отправка сигналов: kill() и killpg()» мы увидим также, что вы можете отправить сигнал всем процессам в определенной группе процессов. (Всегда применяется проверка прав доступа; вы не можете послать сигнал процессу, которым не владеете.)

9.2.1. Обзор управления заданиями

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

Устройство терминала (физическое или другое) с работающим на нем пользователем называется управляющим терминалом.

Сеанс (session) является коллекцией групп процессов, связанных с управляющим терминалом. На одном терминале имеется лишь один сеанс, с несколькими группами процессов в сеансе. Один процесс назначен лидером сеанса; обычно это оболочка, такая, как Bash, pdksh, zsh или ksh93[93], которая может осуществлять управление заданиями. Мы называем такую оболочку оболочкой, управляющей заданиями.

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

Управляющий терминал также имеет связанный с ним идентификатор группы процессов. Когда пользователь набирает специальный символ, такой, как CTRL-C для «прерывания» или CTRL-Z для «остановки», ядро посылает данный сигнал процессам в группе процессов терминала.

Группе процессов, ID которой совпадает с ID управляющего терминала, разрешено записывать в терминал и читать с него. Эта группа называется приоритетной (foreground) группой процессов. (Она получает также генерируемые клавиатурой сигналы.) Любые другие группы процессов в сеансе являются фоновыми (background) группами процессов и не могут читать или записывать в терминал; они получают специальные сигналы, которые их останавливают, если они пытаются это делать.

Задания переходят из приоритетного режима в фоновый и обратно не путем изменения атрибута задания, но посредством изменения группы процессов управляющего терминала. Это изменение осуществляет именно контролирующая задания оболочка, и если новая группа процессов останавливается, оболочка вновь запускает ее, посылая сигнал «продолжить» всем членам группы процессов.

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

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

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

9.2.2. Идентификация группы процессов: getpgrp() и getpgid()

Для совместимости с более старыми системами POSIX предоставляет множество способов получения сведений о группе процессов:

#include <unistd.h>

pid_t getpgrp(void);      /* POSIX */

pid_t getpgid(pid_t pid); /* XSI */

Функция getpgrp() возвращает ID группы процессов текущего процесса. getpgid() является расширением XSI. Она возвращает ID группы процессов для данного pid группы процессов. pid, равный 0, означает «группа процессов текущего процесса». Таким образом, 'getpgid(0)' является тем же самым, что и 'getpgrp()'. При обычном программировании следует использовать getpgrp().

В BSD 4.2 и 4.3 также есть функция getpgrp(), но она действует как функция POSIX getpgid(), требуя аргумент pid. Поскольку современные системы поддерживают POSIX, в новом коде следует использовать версию POSIX. (Если вы думаете, что это сбивает с толку, вы правы. Несколько способов для получения одного и того же результата является обычным итогом проектирования комитетом, поскольку комитет считает, что он должен удовлетворить каждого.)

9.2.3. Установка группы процесса: setpgid() и setpgrp()

Две функции устанавливают группу процесса:

#include <unistd.h>

int setpgid(pid_t pid, pid_t pgid); /* POSIX */

int setpgrp(void);                  /* XSI */

Функция setpgrp() проста: она устанавливает ID группы процесса равной ID процесса. Это создает новую группу процессов в том же сеансе, а вызывающий функцию процесс становится лидером группы процессов.

Функция setpgid() предназначена для использования управления заданиями. Она позволяет одному процессу устанавливать группу процесса для другого. Процесс может изменить лишь свой собственный ID группы процессов или ID группы процессов порожденного процесса, лишь если этот порожденный процесс не выполнил еще exec. Управляющая заданиями оболочка делает этот вызов после fork как в родительском, так и в порожденном процессах. Для одного из них вызов завершается успехом, и ID группы процессов изменяется. (В противном случае нет способа гарантировать упорядочение, когда родитель может изменить ID группы процессов порожденного процесса до того, как последний выполнит exec. Если сначала успешно завершится вызов родителя, он может перейти на следующую задачу, такую, как обработка других заданий или управление терминалом.)