Часть 2 Процессы, IPC и интернационализация
Глава 9
Управление процессами и каналы
Как мы говорили в главе 1 «Введение», если бы нужно было резюмировать Unix (а следовательно, и Linux) в трёх словах, это были бы «файлы и процессы». Теперь, когда мы увидели, как работать с файлами и каталогами, время взглянуть на оставшуюся часть утверждения: процессы. В частности, мы исследуем, как создаются и управляются процессы, как они взаимодействуют с открытыми файлами и как они могут взаимодействовать друге другом. Последующие главы исследуют сигналы — грубый способ дать возможность одному процессу (или ядру) сообщить другому о том, что произошло некоторое событие — и проверку прав доступа.
В данной главе картина начинает усложняться. В частности, для полноты мы должны упомянуть о вещах, которые не будут рассматриваться до конца главы или до конца книги В таких случаях мы предусмотрели ссылки вперед, но вы должны быть способны без подготовки уловить суть каждого раздела.
9.1. Создание и управление процессами
В отличие от многих предшествующих и последующих операционных систем, создание процессов в Unix задумывалось (и было сделано) дешевым. Более того, Unix разделяет идеи «создания нового процесса» и «запуска данной программы в процессе». Это было элегантное проектное решение, которое упрощает многие операции.
9.1.1. Создание процесса: fork()
Первым шагом в запуске новой программы является вызов
fork()
:
#include /* POSIX */
#include
pid_t fork(void);
Использование
fork()
просто. Перед вызовом один процесс, который мы называем родительским, является запущенным. Когда fork()
возвращается, имеется уже два процесса: родительский и порожденный (child).
Вот ключ: оба процесса выполняют одну и ту же программу. Два процесса могут различить себя, основываясь на возвращённом
fork()
значении:
Отрицательное
Если была ошибка,
fork()
возвращает -1, а новый процесс не создается. Работу продолжает первоначальный процесс.
Нулевое
В порожденном процессе
fork()
возвращает 0.
Положительное
В родительском процессе
fork()
возвращает положительный идентификационный номер (PID) порожденного процесса.
Код шаблона для создания порожденного процесса выглядит следующим образом:
pid_t child;
if ((child = fork()) < 0)
/* обработать ошибку */
else if (child == 0)
/* это новый процесс */
else
/* это первоначальный родительский процесс */
pid_t
является знаковым целым типом для хранения значений PID. Скорее всего, это просто int
, но специальный тип делает код более понятным, поэтому он должен использоваться вместо int
.
На языке Unix, помимо названия системного вызова, слово «fork» является и глаголом, и существительным[88]. Мы можем сказать, что «один процесс ответвляет другой», и что «после разветвления работают два процесса». (Думайте «развилка (fork) на дороге», а не «вилка (fork), нож и ложка».)
9.1.1.1. После fork()
: общие и различные атрибуты
Порожденный процесс «наследует» идентичные копии большого числа атрибутов от родителя. Многие из этих атрибутов специализированы и здесь неуместны. Поэтому следующий список намеренно неполон. Существенны следующие:
• Окружение, см. раздел 2.4 «Окружение».
• Все открытые файлы и открытые каталоги; см. раздел 4.4.1 «Понятие о дескрипторах файлов» и раздел 5.3.1 «Базовое чтение каталогов».
• Установки umask; см. раздел 4.6 «Создание файлов».
• Текущий рабочий каталог; см раздел 8.4.1 «Смена каталога:
chdir()
и fchdir()
.
• Корневой каталог; см. раздел 8.6 «Изменение корневого каталога:
chroot()
».
• Текущий приоритет (иначе называемый «значение nice»; вскоре мы это обсудим; см раздел 9.1.3 «Установка приоритета процесса:
nice()
»).
• Управляющие терминалы. Это устройство терминала (физическая консоль или окно эмулятора терминала), которому разрешено посылать процессу сигналы (такие, как CTRL-Z для прекращения выполняющихся работ). Это обсуждается далее в разделе 9.2.1 «Обзор управления работой».
• Маска сигналов процесса и расположение всех текущих сигналов (еще не обсуждалось; см. главу 10 «Сигналы»).
• Реальный, эффективный и сохраненный ID пользователя, группы и набора дополнительных групп (еще не обсуждалось; см. главу 11 «Права доступа и ID пользователя и группы»).
Помимо возвращаемого значения
fork()
два процесса различаются следующим образом:
• У каждого есть уникальный ID процесса и ID родительского процесса (PID и PPID) Они описаны в разделе 9.1.2 «Идентификация процесса:
getpid()
и getppid()
».
• PID порожденного процесса не будет равняться ID любой существующей группы процессов (см. раздел 9.2 «Группы процессов»).
• Аккумулированное время использования процессора для порожденного процесса и его будущих потомков инициализируется нулем. (Это имеет смысл; в конце концов, это совершенно новый процесс.)
• Любые сигналы, которые были ожидающими в родительском процессе, в порожденном сбрасываются, также как ожидающие аварийные сигналы и таймеры. (Мы еще не рассматривали эти темы; см. главу 10 «Сигналы» и раздел 14.3.3 «Интервальные таймеры:
setitimer()
и getitimer()
».)
• Блокировки файлов в родительском процессе не дублируются в порожденном (также еще не обсуждалось; см. раздел 14.2 «Блокировка файлов»).
9.1.1.2. Разделение дескрипторов файлов
Атрибуты, которые порожденный процесс наследует от родителя, устанавливаются в те же значения, которые были в родительском процессе в момент выполнения
fork()
. Однако, с этого момента два процесса продолжают идти собственными путями (большей частью) независимо один от другого. Например, если порожденный процесс изменяет каталог, каталог родительского процесса не затрагивается. Сходным образом, если порожденный изменяет среду, среда родителя не меняется.
Открытые файлы являются важным исключением из этого правила. Дескрипторы открытых файлов являются разделяемыми, и действия одного процесса с разделяемым дескриптором файла затрагивает состояние файла также и для другого процесса. Это лучше всего понять, изучив рис. 9.1.
Рис. 9.1. Разделение дескрипторов файлов
Рисунок отображает внутренние структуры данных ядра. Ключевой структурой данных является таблица файлов. Каждый элемент ссылается на открытый файл. Помимо других учетных данных, таблица файлов содержит текущее положение (смещение чтения/записи) в файле. Оно устанавливается либо автоматически каждый раз при чтении или записи файла, либо непосредственно через
lseek()
(см. раздел 4.5 «Произвольный доступ: перемещения внутри файла»).
Дескриптор файла, возвращенный функциями
open()
или creat()
, действует как индекс имеющегося в каждом процессе массива указателей на таблицу файлов. Размер этого массива не превышает значение, возвращенное getdtablesize()
(см. раздел 4.4.1 «Понятие о дескрипторах файлов»).
На рис. 9.1 показаны два процесса, разделяющие стандартный ввод и стандартный вывод; для каждого из процессов указаны одни и те же элементы в таблице файлов. Поэтому, когда процесс 45 (порожденный) осуществляет
read()
, общее смещение обновляется; следующий раз, когда процесс 42 (родитель) осуществляет read()
, он начинает с позиции, в которой закончила чтение read()
процесса 45.
Это легко можно видеть на уровне оболочки:
$ cat data /* Показать содержание демонстрационного файла */
line 1
line 2
line 3
line 4
$ ls -l test1 ; cat test1 /* Режим и содержание тестовой программы */
-rwxr-xr-x 1 arnold devel 93 Oct 20 22:11 test1
#! /bin/sh
read line ; echo p: $line /* Прочесть строку в родительской оболочке,
вывести ее */
( read line ; echo с: $line ) /* Прочесть строку в порожденной оболочке,
вывести ее */
read line ; echo p: $line /* Прочесть строку в родительской оболочке,
вывести ее */
$ test1 < data /* Запустить программу */
p: line 1 /* Родитель начинает сначала */
c: line 2 /* Порожденный продолжает оттуда, где остановился родитель */
p: line 3 /* Родитель продолжает оттуда, где остановился порожденный */
Первая исполняемая строка
test1
читает из стандартного ввода строку, изменяя смещение файла. Следующая строка test1
запускает команды, заключенные между скобками, в подоболочке (subshell). Это отдельный процесс оболочки, созданный — как вы догадались — с помощью fork()
. Порожденная подоболочка наследует от родителя стандартный ввод, включая текущее смещение. Этот процесс читает строку и обновляет разделяемое смещение в файле. Когда третья строка, снова в родительской оболочке, читает файл, она начинает там, где остановился порожденный.
Хотя команда
read
встроена в оболочку, все работает таким же образом и для внешних команд. В некоторых ранних Unix-системах была команда line
, которая читала одну строку ввода (по одному символу за раз!) для использования в сценариях оболочки; если бы смещение файла не было разделяемым, было бы невозможно использовать такую команду в цикле.
Разделение дескрипторов файлов и наследование играют центральную роль в перенаправлении ввода/вывода оболочки; системные вызовы и их семантика делают примитивы уровня оболочки простыми для реализации на С, как мы позже увидим в данной главе.
9.1.1.3. Разделение дескрипторов файлов и close()
Тот факт, что несколько дескрипторов файлов могут указывать на один и тот же открытый файл, имеет важное следствие: файл не закрывается до тех пор, пока не будут закрыты все дескрипторы файла.
Позже в главе мы увидим, что несколько дескрипторов для одного файла могут существовать не только для разных процессов, но даже и внутри одного и того же процесса; это правило особенно важно для работы с каналами (pipes).
Если вам нужно узнать, открыты ли два дескриптора для одного и того же файла, можете использовать
fstat()
(см. раздел 5.4.2 «Получение сведений о файле») для двух дескрипторов с двумя различными структурами struct stat
. Если соответствующие поля st_dev
и st_ino
равны, это один и тот же файл.
Позже в главе мы завершим обсуждение манипуляций с дескрипторами файлов и таблицей дескрипторов файлов.
9.1.2. Идентификация процесса: getpid()
и getppid()
У каждого процесса есть уникальный ID номер процесса (PID). Два системных вызова предоставляют текущий PID и PID родительского процесса:
#include /* POSIX */
#include
pid_t getpid(void);
pid_t getppid(void);
Функции так просты, как выглядят:
pid_t getpid(void)
Возвращает PID текущего процесса
pid_t getppid(void)
Возвращает PID родителя.
Значения PID уникальны; по определению, не может быть двух запущенных процессов с одним и тем же PID. PID обычно возрастают в значении, так что порожденный процесс имеет обычно больший PID, чем его родитель. Однако, на многих системах значения PID переполняются; когда достигается значение системного максимума для PID, следующий процесс создается с наименьшим не используемым номером PID. (Ничто в POSIX не требует такого поведения, и некоторые системы назначают неиспользуемые номера PID случайным образом.)
Если родительский процесс завершается, порожденный получает нового родителя,
init
. В этом случае PID родителя будет 1, что является PID init
. Такой порожденный процесс называется висячим (orphan). Следующая программа, ch09-reparent.с
, демонстрирует это. Это также первый пример fork()
в действии:
1 /* ch09-reparent.c --- показывает, что getppid() может менять значения */
2
3 #include
4 #include
5 #include
6 #include
7
8 /* main --- осуществляет работу */
9
10 int main(int argc, char **argv)
11 {
12 pid_t pid, old_ppid, new_ppid;
13 pid_t child, parent;
14
15 parent = getpid(); /* перед fork() */
16
17 if ((child = fork()) < 0) {
18 fprintf(stderr, "%s: fork of child failed: %s\n",
19 argv[0], strerror(errno));
20 exit(1);
21 } else if (child == 0) {
22 old_ppid = getppid();
23 sleep(2); /* см. главу 10 */
24 new_ppid = getppid();
25 } else {
26 sleep(1);
27 exit(0); /* родитель завершается после fork() */
28 }
29
30 /* это выполняет только порожденный процесс */
31 printf("Original parent: %d\n", parent);
32 printf("Child: %d\n", getpid());
33 printf("Child's old ppid: %d\n", old_ppid);
34 printf("Child's new ppid: %d\n", new_ppid);
35
36 exit(0);
37 }
Строка 15 получает PID начального процесса, используя
getpid()
. Строки 17–20 создают порожденный процесс, проверяя по возвращении ошибки.
Строки 21–24 выполняются порожденным процессом: строка 22 получает PPID. Строка 23 приостанавливает процесс на две секунды (сведения о
sleep()
см в разделе 10.8.1 «Аварийные часы: sleep()
, alarm()
и SIGALRM
»), а строка 24 снова получает PPID.
Строки 25–27 исполняются в родительском процессе. Строка 26 задерживает родителя на одну секунду, давая порожденному процессу достаточно времени для осуществления первого вызова
getppid()
. Строка 27 завершает родителя.
Строки 31–34 выводят значения. Обратите внимание, что переменная
parent
, которая была установлена до разветвления, сохраняет свое значение в порожденном процессе. После порождения у двух процессов идентичные, но независимые копии адресного пространства. Вот что происходит при запуске программы:
$ ch09-reparent /* Запуск программы */
$ Original parent: 6582 /* Программа завершается: приглашение оболочки
и вывод порожденного процесса */
Child: 6583
Child's old ppid: 6582
Child's new ppid: 1
Помните, что обе программы выполняются параллельно. Графически это изображено на рис. 9.2.
Рис. 9.2. Два параллельно исполняющихся процесса после разветвления
ЗАМЕЧАНИЕ. Использование
sleep()
, чтобы заставить один процесс пережить другой, работает в большинстве случаев. Однако, иногда случаются ошибки, которые трудно воспроизвести и трудно обнаружить. Единственным способом гарантировать правильное поведение является явная синхронизация с помощью wait()
или waitpid()
, которые описываются далее в главе (см. раздел 9.1.6.1 «Использование функций POSIX: wait()
и waitpid()
»).
9.1.3. Установка приоритетов процесса: nice()
Когда процессы запущены, ядро динамически меняет приоритет каждого процесса. Как и в жизни, элементы с большим приоритетом получают внимание до элементов с меньшим приоритетом. Короче говоря, каждому процессу выделяется небольшая порция времени для исполнения, которая называется квантом времени (time slice). Когда квант истекает, если текущий процесс все еще является процессом с наивысшим приоритетом, ему разрешается продолжать.
Linux, как и Unix, обеспечивает вытесняющую многозадачность. Это означает, что ядро может вытеснить процесс (приостановить его), если настало время дать возможность поработать другому процессу. Приоритет длительное время работающих процессов (например, процессов, выполняющих интенсивные вычисления), снижается в конце их кванта времени, поэтому они дают шанс другим процессам получить время процессора. Сходным образом, процессам, длительное время бездействовавшим в ожидании завершения ввода/вывода (таким, как интерактивный текстовый редактор), приоритет повышается, так что они могут ответить на ввод/вывод, когда он происходит. Короче, ядро гарантирует, что все процессы, усредненные по времени, получают свою «справедливую долю» времени процессора. Повышение и понижение приоритетов является частью этого процесса.
Проектирование хорошего планировщика процессов для ядра является искусством; практические подробности выходят за рамки данной книги. Однако, процесс может влиять на назначения приоритетов ядром посредством своего значения относительного приоритета (nice).
Значение относительного приоритета является указанием того, насколько «приятным» хочет быть процесс в отношении других процессов. В соответствии с этим большие значения означают во все большей степени терпеливые процессы; т.е. те, которые все более приятны другим, снижая свой приоритет по отношению к ним.
Отрицательное значение относительного приоритета, с другой стороны, означает, что процесс желает быть «менее приятным» по отношению к другим. Такой процесс более эгоистичный, требуя себе большего количества времени процессора[89]. К счастью, в то время как пользователи могут повышать значение относительного приоритета (быть более приятными), лишь
root
может снижать значение относительного приоритета (быть менее приятным).
Значение относительного приоритета является лишь одним фактором в уравнении, используемом ядром для вычисления приоритета; это не значение самого приоритета, которое изменяется с течением времени на основе поведения процесса и состояния других процессов системы. Для изменения значения относительного приоритета используется системный вызов
nice()
:
#include /* XSI */
int nice(int inc);
Значение относительного приоритета по умолчанию равно 0. Разрешен диапазон значений от -20 до 19. Это требует некоторой привычки. Чем более отрицательное значение, тем выше приоритет процесса: -20 является наивысшим приоритетом (наименьшая приятность), а 19 — наинизшим приоритетом (наибольшая приятность)
Аргумент
inc
является приращением, на который надо изменить значение приоритета. Для получения текущего значения, не изменяя его, используйте 'nice(0)
'. Если результат 'текущий_относительный_приоритет + inc
' выйдет за пределы от -20 до 19, система принудительно включит его в этот диапазон.
Возвращаемое значение является новым значением относительного приоритета или -1, если возникла ошибка. Поскольку -1 также является действительным значением относительного приоритета, при вызове
nice()
следует сначала явным образом установить errno
в ноль, а затем проверить его насчет имевшихся проблем:
int niceval;
int inc = /* любое значение */;
errno = 0;
if ((niceval = nice(inc)) < 0 && errno != 0) {
fprintf(stderr, "nice(%d) failed: %s\n", inc, strerror(errno));
/* другое восстановление */
}
Этот пример может завершиться неудачей, если в
inc
отрицательное значение, а процесс не запущен как root
.
9.1.3.1. POSIX против действительности
Диапазон значений относительного приоритета от -20 до 19, которые использует Linux, имеет исторические корни; он ведет начало по крайней мерее V7. POSIX выражает состояние менее прямым языком, что дает возможность большей гибкости, сохраняя в то же время историческую совместимость. Это также затрудняет чтение и понимание стандарта, вот почему вы и читаете эту книгу. Итак, вот как описывает это POSIX
Во-первых, значение относительного приоритета процесса, поддерживаемое системой, колеблется от 0 до '
(2 * NZERO) - 1
'. Константа NZERO
определена в
и должна равняться по крайней мере 20. Это дает диапазон 0–39.
Во-вторых, как мы описывали, сумма текущего значения относительного приоритета и приращение
incr
загоняются в этот диапазон.
В заключение, возвращаемое
nice()
значение является значением относительного приоритета процесса минус NZERO
. При значении NZERO
20 это дает первоначальный диапазон от -20 до 19, который мы описали вначале.
Результатом является то, что возвращаемое nice() значение в действительности изменяется от '
-NZERO
' до 'NZERO-1
', и лучше всего писать свой код в терминах этой именованной константы. Однако, на практике трудно найти систему, в которой NZERO
не было бы равно 20.
9.1.4. Запуск новой программы: семейство exec()
После запуска нового процесса (посредством
fork()
) следующим шагом является запуск в процессе другой программы. Имеется несколько функций, которые служат различным целям:
#include /* POSIX */
int execve(const char *filename, /* Системный вызов */
char *const argv[], char *const envp[]);
int execl(const char *path, const char *arg, ...); /* Оболочки */
int execlp(const char *file, const char *arg, ...);
int execle(const char *path, const char *arg, ..., char *const envp[]);
int execv(const char *path, char *const argv[]);
int execvp(const char *file, char *const argv[]);
Мы ссылаемся на эти функции как на «семейство
exec()
». Функции с именем exec()
нет; вместо этого мы используем это имя для обозначения любой из перечисленных выше функций. Как и в случае с fork()
, «exec
» используется на языке Unix и в качестве глагола, означающего исполнение (запуск) программы, и в качестве существительного.
9.1.4.1. Системный вызов execve()
Простейшей для объяснения функцией является
execve()
. Она является также лежащим в основе системным вызовом. Другие являются функциями-оболочками, как вскоре будет объяснено.
int execve(const char *filename, char *const argv[],
char* const envp[]);
filename
является именем программы для исполнения. Это может быть именем полного или относительного пути. Файл должен иметь формат исполняемого файла, который понимает ядро. Современные системы используют формат исполняемого файла ELF (Extensible Linking Format — открытый формат компоновки). GNU/Linux распознает ELF и несколько других форматов. С помощью execve()
можно исполнять интерпретируемые сценарии, если они используют особую первую строку с именем интерпретатора, начинающуюся с '#!
'. (Сценарии, которые не начинаются с '#!
', потерпят неудачу.) В разделе 1.1.3 «Исполняемые файлы» представлен пример использования '#!'. argv является стандартным списком аргументов С — массив символьных указателей на строки аргументов, включая значение для использования с argv[0]
[90], завершающийся указателем NULL
.
envp
является окружением для использования новым процессом, с таким же форматом, как глобальная переменная environ
(см. раздел 2.4 «Переменные окружения»). В новой программе это окружение становится начальным значением environ
.
Программа не должна возвращаться из вызова
exec()
. Если она возвращается, возникла проблема. Чаще всего либо не существует затребованная программа, либо она существует, но не является исполняемой (значения для errno ENOENT
и EACCESS
соответственно). Может быть множество других ошибок; см. справочную страницу execve(2).
В предположении, что вызов был успешным, текущее содержимое адресного пространства процесса сбрасывается. (Ядро сначала сохраняет в безопасном месте данные
argv
и envp
.) Ядро загружает для новой программы исполняемый код вместе со всеми глобальными и статическими переменными. Затем ядро инициализирует переменные окружения переданными execve()
данными, а далее вызывает процедуру main()
новой программы с переданным функции execve()
массивом argv
. Подсчитывается число аргументов и это значение передается main()
в argc
.
К этому моменту новая программа запущена. Она не знает (и не может определить), какая программа была в процессе до нее. Обратите внимание, что ID процесса не меняется. Многие другие атрибуты при вызове
exec
сохраняются; вскоре мы рассмотрим это более подробно.
exec()
для процесса можно сравнить с ролями, которые играют в жизни люди. В различное время в течение дня один человек может быть родителем, супругом, другом, студентом или рабочим, покупателем в магазине и т.д. Это одна и та же личность, исполняющая различные роли. Также и процесс — его PID, открытые файлы, текущий каталог и т.п. — не изменяются, тогда как выполняемая работа - запущенная с помощью exec()
программа — может измениться.
9.1.4.2. Функции-оболочки: execl()
и др.
Пять дополнительных функций, действующих в качестве оболочек, предоставляют более удобные интерфейсы для
execve()
. В первой группе все принимают список аргументов, каждый из которых передается в виде явного параметра функции:
int execl(const char *path, const char *arg, ...)
Первый аргумент,
path
, является путем к исполняемому файлу. Последующие аргументы, начиная с arg
, являются отдельными элементами, которые должны быть помещены в argv
. Как и ранее, явным образом должен быть включен argv[0]
. Вы должны в качестве последнего аргумента передать завершающий указатель NULL
, чтобы execl()
смогла определить, где заканчивается список аргументов. Новая программа наследует любые переменные окружения, которые находятся в переменной environ
.
int execlp(const char *file, const char *arg, ...)
Эта функция подобна
execl()
, но она имитирует механизм поиска команд оболочки, разыскивая file
в каждом каталоге, указанном в переменной окружения PATH
. Если file
содержит символ /
, этот поиск не осуществляется. Если PATH
в окружении не присутствует, execlp()
использует путь по умолчанию. В GNU/Linux по умолчанию используется ":/bin:/usr/bin
", но в других системах может быть другое значение. (Обратите внимание, что ведущее двоеточие в PATH
означает, что сначала поиск осуществляется в текущем каталоге.)
Более того, если файл найден и имеет право доступа на исполнение, но не может быть исполнен из-за того, что неизвестен его формат,
execlp()
считает, что это сценарий оболочки и запускает оболочку с именем файла в качестве аргумента.
int execle(const char *path, const char *arg, ...,
char *const envp[])
Эта функция также подобна
execl()
, но принимает дополнительный аргумент, envp
, который становится окружением новой программы. Как и в случае с execl()
, вы должны для завершения списка аргументов поместить перед envp
указатель NULL
.
Вторая группа функций-оболочек принимает массив в стиле
argv
:
int execv(const char *path, char *const argv[])
Эта функция подобна
execve()
, но новая программа наследует любое окружение, которое находится в переменной environ текущей программы.
int execvp(const char *file, char *const argv[])
Эта функция подобна
execv()
, но она осуществляет такой же поиск в PATH
, как и функция execlp()
. Она также переходит на исполнение сценария оболочки, если найденный файл не может быть исполнен непосредственно.
В табл. 9.1 подведены итоги для шести функций
exec()
.
Таблица 9.1. Сводка семейства функций
exec()
по алфавиту
Функция
Поиск пути
Окружение пользователя
Назначение
execl()
√
Исполняет список аргументов.
execle()
Исполняет список аргументов с окружением.
execlp()
√
√
Исполняет список аргументов с поиском пути
execv()
√
Исполняет с argv
execve()
Исполняет с argv
и окружением (системный вызов).
execvp()
√
√
Исполняет с argv
и с поиском пути
Функций
execlp()
и execvp()
лучше избегать, если вы не знаете, что переменная окружения PATH
содержит приемлемый список каталогов.
9.1.4.3. Имена программ и argv[0]
До сих пор мы все время считали
argv[0]
именем программы. Мы знаем, что оно может содержать, а может и не содержать символ /
, в зависимости от способа вызова программы, если этот символ содержится, это хорошая подсказка к тому, что для вызова программы использовалось имя пути.
Однако, как должно быть ясно к этому времени, то, что
argv[0]
содержит имя файла, является лишь соглашением. Ничто не может воспрепятствовать передаче вами вызываемой программе в качестве argv[0]
произвольной строки. Следующая программа, ch09-run.c
, демонстрирует передачу произвольной строки:
1 /* ch09-run.c --- запуск программы с другим именем и любыми аргументами */
2
3 #include
4 #include
5 #include
6
7 /* main --- настроить argv и запустить указанную программу */
8
9 int main(int argc, char **argv)
10 {
11 char *path;
12
13 if (argc < 3) {
14 fprintf(stderr, "usage: %s path arg0 [ arg ... ]\n", argv[0]);
15 exit(1);
16 }
17
18 path = argv[1];
19
20 execv(path, argv + 2); /* skip argv[0] and argv[1] */
21
22 fprintf(stderr, "%s: execv() failed: %s\n", argv[0],
23 strerror(errno));
24 exit(1);
25 }
Первый аргумент является путем к запускаемой программе, а второй аргумент является новым именем для программы (которое большинство утилит игнорируют, кроме сообщений об ошибках); все остальные аргументы передаются вызываемой программе.
Строки 13–16 осуществляют проверку ошибок. Строка 18 сохраняет путь в
path
Строка 20 осуществляет exec
; если программа доходит до строк 22–23, это указывает на ошибку. Вот что происходит при запуске программы:
$ ch09-run /bin/grep whoami foo /* Запустить grep */
a line /* Входная строка не подходит */
a line with foo in it /* Входная строка подходит */
a line with foo in it /* Это выводится */
^D /* EOF */
$ ch09-run nonexistent-program foo bar /* Демонстрация неудачи */
ch09-run: execv() failed: No such file or directory
Следующий пример несколько неестественен: мы заставили
ch09-run
запустить себя, передав в качестве имени программы 'foo
'. Поскольку аргументов для второго запуска недостаточно, она выводит сообщение об использовании и завершается:
$ ch09-run ./ch09-run foo
usage: foo path arg() [ arg ... ]
Хотя она и не очень полезна,
ch09-run
ясно показывает, что argv[0]
не обязательно должен иметь какое-нибудь отношение к файлу, который в действительности запускается.
В System III (примерно в 1980-м) команды
cp
, ln
и mv
представляли один исполняемый файл с тремя ссылками с этими именами в /bin
. Программа проверяла argv[0]
и решала, что она должна делать. Это сохраняло некоторое количество дискового пространства за счет усложнения исходного кода и форсирования выполнения программой действия по умолчанию при запуске с неизвестным именем. (Некоторые современные коммерческие системы Unix продолжают эту практику!) Без явной формулировки причин GNU Coding Standards рекомендует, чтобы программы не основывали свое поведение на своем имени. Одна причина, которую мы видели, состоит в том, что администраторы часто устанавливают GNU версию утилиты наряду со стандартной версией коммерческих систем Unix, используя префикс g: gmake
, gawk
и т.д. Если такие программы ожидают лишь стандартные имена, они при запуске с другим именем потерпят неудачу.
Сегодня также дисковое пространство дешево; если из одного и того же исходного кода можно построить две почти идентичные программы, лучше это сделать, использовав
#ifdef
, что у вас есть. Например, grep
и egrep
имеют значительную часть общего кода, но GNU версия строит два отдельных исполняемых файла.
9.1.4.4. Атрибуты, наследуемые exec()
Как и в случае с
fork()
, после вызова программой exec
сохраняется ряд атрибутов:
• Все открытые файлы и открытые каталоги; см. раздел 4.4.1 «Понятие о дескрипторах файлов» и раздел 3.3.1 «Базовое чтение каталогов». (Сюда не входят файлы, помеченные для закрытия при исполнении (close-on-exec), как описано далее в этой главе; см. раздел 9.4.3.1 «Флаг close-on-exec».)
• Установки umask; см. раздел 4.6 «Создание файлов».
• Текущий рабочий каталог, см. раздел 8.4.1 «Изменение каталога:
chdir()
и fchdir()
»
• Корневой каталог; см. раздел 8.6 «Изменение корневого каталога:
chroot()
».
• Текущее значение относительного приоритета.
• ID процесса и ID родительского процесса.
• ID группы процесса и контролирующий терминал; см. раздел 9.2.1 «Обзор управления работами».
• Маску сигналов процесса и любые ожидающие сигналы, а также любые не истекшие аварийные сигналы или таймеры (здесь не обсуждается; см. главу 10 «Сигналы»).
• Действительные ID пользователя и ID группы, а также дополнительный набор групп. Эффективные ID пользователя и группы (а следовательно, и сохраненные ID set-user и set-group) могут быть установлены с помощью битов setuid и setgid исполняемого файла. (Ничто из этого пока не обсуждалось; см. главу 11 «Права доступа и ID пользователя и группы».)
• Блокировки файлов сохраняются (также пока не обсуждалось; см. раздел 14.2 «Блокировка файлов»).
• Суммарное использованное время процессора для процесса и его потомков не меняется.
После
exec
размещение сигналов изменяется; дополнительные сведения см. в разделе 10.9 «Сигналы для fork()
и exec()
».
После
exec
все открытые файлы и каталоги остаются открытыми и доступными для использования. Вот как программы наследуют стандартные ввод, вывод и ошибку: они на месте, когда программа запускается.
В большинстве случаев при исполнении
fork
и exec
для отдельной программы не нужно ничего наследовать, кроме дескрипторов файлов 0, 1 и 2. В этом случае можно вручную закрыть все другие открытые файлы в порожденном процессе после выполнения fork
и до выполнения exec
. В качестве альтернативы можно пометить дескриптор файла для автоматического закрытия системой при исполнении exec; эта последняя возможность обсуждается далее в главе (см раздел 9.4.3.1 «Флаг close-on-exec».)
9.1.5. Завершение процесса
Завершение процесса включает два шага: окончание процесса с передачей системе статуса завершения и восстановление информации родительским процессом.
9.1.5.1. Определение статуса завершения процесса
Статус завершения (exit status) (известный также под другими именами значения завершения (exit value), кода возврата (return code) и возвращаемого значения (return value)) представляет собой 8-битовое значение, которое родитель может использовать при завершении порожденного процесса (на языке Unix, «когда порожденный кончается (dies)»). По соглашению статус завершения 0 означает, что программа отработала без проблем. Любое ненулевое значение указывает на какую-нибудь разновидность ошибки; программа определяет используемые числа и их значения, если они есть. (Например,
grep
использует 0 для указания, что образец был встречен по крайней мере один раз, 1 означает, что образец вообще не встретился, а 2 означает, что возникла ошибка.) Этот статус завершения доступен на уровне оболочки (для оболочек в стиле оболочки Борна) через специальную переменную $?
.
Стандарт С определяет две константы, которые следует использовать для полной переносимости на не-POSIX системы:
EXIT_SUCCESS
Программа завершилась без проблем. Для обозначения успеха может также использоваться ноль.
EXIT
_FAILURE
В программе была какая-нибудь проблема.
На практике использование лишь этих значений довольно ограничивает. Вместо этого следует выбрать небольшой набор кодов возврата, документировать их значения и использовать. (Например, 1 для ошибок опций командной строки и аргументов, 2 для ошибок ввода/вывода, 3 для ошибок данных и т.д.) Для удобочитаемости стоит использовать константы
#define
или значения enum
. Слишком большой список ошибок делает их использование обременительным; в большинстве случаев вызывающая программа (или пользователь) интересуется лишь нулевым или ненулевым значением.
Когда достаточно двоичного разделения успех/неудача, педантичный программист использует
EXIT_SUCCESS
и EXIT_FAILURE
. Наш собственный стиль более естественный, используя с return
и exit()
явные константы 0 или 1. Это настолько обычно, что рано заучивается и быстро становится второй натурой. Однако для своих проектов вы сами должны принять решение.
ЗАМЕЧАНИЕ. Для родительского процесса доступны лишь восемь наименее значимых битов значения. Поэтому следует использовать значения в диапазоне 0–255. Как мы вскоре увидим, у чисел 126 и 127 есть традиционные значения (помимо простого «неуспешно»), которых ваши программы должны придерживаться.
Поскольку имеют значение лишь восемь наименее значимых битов, вы никогда не должны использовать отрицательные статусы завершения. Когда из небольших отрицательных чисел выделяются восемь последних битов, они превращаются в большие положительные значения! (Например. -1 становится 255, а -5 становится 251.) Мы видели книги по программированию на С, в которых это понималось неправильно — не дайте сбить себя с толку
9.1.5.2. Возвращение из main()
Программа может естественно завершиться одним из двух способов: посредством использования одной из описанных далее функций или возвратившись из
main()
. (Третий, более радикальный способ описан далее в разделе 12.4 «Совершение самоубийства: abort()
».) В последнем случае следует использовать явное возвращаемое значение вместо выпадения в конце функции:
/* Правильно */ /* Неправильно */
int main(int argc, char **argv) int main(int argc, char **argv)
{ {
/* здесь код */ /* здесь код */
return 0; /* ?? Что возвращает main()? */
} }
Стандарт С 1999 г. указывает, что при выпадении в конце, поведение функции
main()
должно быть таким, как если бы она возвращала 0. (Это верно также для С++; однако, стандарт С 1989 г. намеренно оставляет этот случай неопределенным.) Во всех случаях плохо полагаться на это поведение; однажды вы можете программировать для системы со скудной поддержкой С времени исполнения, или для внедренной системы, или где-то еще, где это будет по-другому. (В общем, выпадение в конце любой функции, не являющейся void
— плохая мысль, которая может вести лишь к ошибочному коду.)
Возвращенное из
main()
значение автоматически передается обратно системе, от которой родительский процесс может его впоследствии получить. Мы опишем, как это делается, в разделе 9.1.6.1 «Использование функций POSIX: wait()
и waitpid()
».
ЗАМЕЧАНИЕ. На системах GNU/Linux управляемая компилятором команда c99 запускает компилятор с соответствующими опциями, так что возвращаемое значение при выпадении из конца функции равно 0. Простой gcc этого не делает.
9.1.5.3. Функции завершения
Другим способом естественного завершения программы является вызов функций завершения. Стандарт С определяет следующие функции:
#include /* ISO С */
void exit(int status);
void _Exit(int status);
int atexit(void (*function)(void));
Эти функции работают следующим образом:
void exit(int status)
Эта функция завершает программу,
status
передается системе для использования родителем. Перед завершением программы exit()
вызывает все функции, зарегистрированные с помощью atexit()
, сбрасывает на диск и закрывает все открытые потоки <stdio.h> FILE
* и удаляет все временные файлы, созданные tmpfile()
(см. раздел 12.3.2 «Создание и открытие временных файлов»). Когда процесс завершается, ядро закрывает любые оставшиеся открытыми файлы (которые были открыты посредством open()
, creat()
или через наследование дескрипторов), освобождает его адресное пространство и освобождает любые другие ресурсы, которые он мог использовать. exit()
никогда не возвращается.
void _Exit(int status)
Эта функция в сущности идентична функции POSIX
_exit()
; мы на короткое время отложим ее обсуждение,
int atexit(void (*function)(void))
function
является указателем на функцию обратного вызова, которая должна вызываться при завершении программы, exit()
запускает функцию обратного вызова перед закрытием файлов и завершением. Идея в том, что приложение может предоставить одну или более функций очистки, которые должны быть запущены перед окончательным завершением работы. Предоставление функции называется ее регистрацией. (Функции обратного вызова для nftw()
обсуждались в разделе 8.4.3.2 «Функция обратного вызова nftw()
»; здесь та же идея, хотя atexit()
вызывает каждую зарегистрированную функцию лишь однажды.)
atexit()
возвращает 0 при успехе или -1 при неудаче и соответствующим образом устанавливает errno
.
Следующая программа не делает полезной работы, но демонстрирует, как работает
atexit()
:
/* ch09-atexit.c --- демонстрация atexit().
Проверка ошибок для краткости опущена. */
/*
* Функции обратного вызова здесь просто отвечают на вызов.
* В настоящем приложении они делали бы больше. */
void callback1(void) { printf("callback1 called\n"); }
void callback2(void) { printf("callback2 called\n"); }
void callback3(void) { printf("callback3 called\n"); }
/* main --- регистрация функций и завершение */
int main(int argc, char **argv) {
printf("registering callback1\n"); atexit(callback1);
printf("registering callback2\n"); atexit(callback2);
printf("registering callback3\n"); atexit(callback3);
printf("exiting now\n");
exit(0);
}
Вот что происходит при запуске:
$ ch09-atexit
registering callback1 /* Запуск главной программы */
registering callback2
registering callback3
exiting now
callback3 called /* Функции обратного вызова запускаются в обратном
порядке */
callback2 called
callback1 called
Как показывает пример, функции, зарегистрированные с помощью
atexit()
, запускаются в порядке, обратном порядку их регистрации: последние первыми. (Это обозначается также LIFO — last-in-first-out — вошедший последним выходит первым).
POSIX определяет функцию
_exit()
. В отличие от exit()
, которая вызывает функции обратного вызова и выполняет
-очистку, _exit()
является «сразу заканчивающейся» функцией:
#include /* POSIX */
void _exit(int status);
Системе передается
status
, как и для exit()
, но процесс завершается немедленно. Ядро все еще делает обычную очистку: все открытые файлы закрываются, использованная адресным пространством память освобождается, любые другие ресурсы, использованные процессом, также освобождаются.
На практике функция
_Exit()
ISO С идентична _exit()
. Стандарт С говорит, что от реализации функции зависит, вызывает ли _Exit()
зарегистрированные atexit()
функции и закрывает ли открытые файлы. Для систем GLIBC это не так, и функция ведет себя подобно _exit()
.
Время использовать
_exit()
наступает, когда exec
в порожденном процессе завершается неудачей. В этом случае вам не нужно использовать обычный exit()
, поскольку это сбрасывает на диск данные буферов, хранящиеся в потоках FILE*
. Когда позже родительский процесс сбрасывает на диск свои копии буферов, данные буфера оказываются записанными дважды; это очевидно нехорошо.
Например, предположим, что вы хотите запустить команду оболочки и хотите сами выполнить
fork
и exec
. Такой код выглядел бы следующим образом:
char *shellcommand = "...";
pid_t child;
if ((child = fork()) == 0) { /* порожденный процесс */
execl("/bin/sh", "sh", "-c", shellcommand, NULL);
_exit(errno == ENOENT ? 127 : 126);
}
/* родитель продолжает */
Проверка значения
errno
и завершающего значения следуют соглашениям, используемым оболочкой POSIX. Если запрошенная программа не существует (ENOENT
— нет для неё элемента в каталоге), завершающее значение равно 127. В противном случае, файл существует, но exec
не могла быть выполнена по какой-то другой причине, поэтому статус завершения равен 126. Хорошая мысль следовать этим соглашениям также и в ваших программах. Вкратце, чтобы хорошо использовать exit()
и atexit()
, следует делать следующее:
• Определить небольшой набор значений статуса завершения, которые ваша программа будет использовать для сообщения этой информации вызывающему. Используйте для них в своем коде константы
#define
или enum
.
• Решить, имеет ли смысл наличие функций обратного вызова для использования с
atexit()
. Если имеет, зарегистрировать их в main()
в соответствующий момент; например, после анализа опций и инициализации всех структур данных, которые функция обратного вызова должна очищать. Помните, что функции должны вызываться в порядке LIFO (последняя вызывается первой).
• Использовать
exit()
для выхода из программы во всех местах, когда что-то идет не так и когда выход является правильным действием. Используйте коды ошибок, которые определили.
• Исключением является
main()
, для которой можно использовать при желании return
. Наш собственный стиль заключается обычно в использовании exit()
при наличии проблем и 'return 0
' в конце main()
, если все прошло хорошо.
• Использовать
_exit()
или _Exit()
в порожденном процессе, если exec() завершается неудачей.
9.1.6. Использование статуса завершения порожденного процесса
Когда процесс заканчивается, нормальным ходом событий для ядра является освобождение всех его ресурсов. Ядро сохраняет статус завершения законченного процесса, также, как сведения о ресурсах, которые он использовал в своей работе, a PID продолжает считаться используемым. Такой завершившийся процесс называется зомби.
Родительский процесс, будь то первоначальный родитель или
init
, может получить статус завершения порожденного процесса. Или, посредством использования функций BDS, которые не стандартизованы POSIX, можно получить статус завершения вместе со сведениями об использовании ресурсов. Использование статуса осуществляется ожиданием окончания процесса: это известно также как пожинание (reaping) процесса[91].
Между механизмами, которые ожидают завершения потомков, и сигнальными механизмами, которые мы еще не обсуждали, есть значительное взаимодействие. Что из них описать вначале представляет собой нечто вроде проблемы курицы и яйца; мы решили сначала поговорить сначала о механизмах ожидания порожденного процесса, а глава 10 «Сигналы» дает полный рассказ о сигналах.
Пока достаточно понять, что сигнал является способом уведомления процесса о том, что произошло некоторое событие. Процессы могут генерировать сигналы, которые посылаются самим себе, или сигналы могут посылаться извне другими процессами или пользователем за терминалом. Например, CTRL-C посылает сигнал «прерывания», a CTRL-Z посылает сигнал управления работой «стоп».
По умолчанию, многие сигналы, такие, как сигнал прерывания, заставляют получающий процесс закончиться. Другие, такие, как сигналы управления работами, вызывают изменение его состояния. Механизмы ожидания порожденного процесса могут определить, претерпел ли процесс сигнал завершения, и если да, какой это был сигнал. То же верно и для остановки процесса и, на некоторых системах возобновления процесса.
9.1.6.1. Использование функций POSIX: wait()
и waitpid()
Первоначальным системным вызовом V7 был
wait()
. Более новым вызовом POSIX, основанным на возможностях BSD, является waitpid()
. Объявления функций следующие:
#include /* POSIX */
#include
pid_t wait(int *status);
pid_t waitpid(pid_t pid, int *status, int options);
wait()
ждет завершения любого порожденного процесса; сведения о том, как он завершился, возвращаются в *status
. (Вскоре мы обсудим, как интерпретировать *status
.) Возвращаемое значение является PID завершившегося процесса или -1, если возникла ошибка.
Если порожденных процессов нет,
wait()
возвращает -1 с errno
, установленным в ECHILD
(отсутствует порожденный процесс). В противном случае, функция ждет завершения первого порожденного процесса или поступления сигнала.
Функция
waitpid()
дает возможность ждать завершения определенного порожденного процесса. Она предоставляет значительную гибкость и является предпочтительной для использования функцией. Она также возвращает PID закончившегося процесса или -1 при возникновении ошибки. Аргументы следующие:
pid_t pid
Значение указывает, завершения какого порожденного процесса ждать как по-настоящему
pid
, так и по группе процесса. Смысл значения pid
следующий:
pid < -1
Ждать завершения любого порожденного процесса с ID группы процесса, равной абсолютному значению pid
.
pid = -1
Ждать завершения любого порожденного процесса. Таким способом работает wait()
.
pid = 0
Ждать завершения любого порожденного процесса с ID группы процесса, равной ID группе родительского процесса.
pid > 0
Ждать завершения конкретного процесса с PID, равным pid
.
int *status
То же, что и для
wait()
.
определяет различные макросы, которые интерпретируют значение в *status
, которые мы вскоре опишем
int options
Этот параметр должен быть равен либо 0, либо побитовым ИЛИ одного или более из следующих флагов:
WNOHANG
Если ни один порожденный процесс не завершился, вернуться немедленно. Таким способом можно периодически проверять, не закончился ли какой- нибудь порожденный процесс. (Такая периодическая проверка известна как опрашивание события.)
WUNTRACED
Вернуть сведения о порожденном процессе, который остановился, но еще не завершился. (Например, для управления работой.)
WCONTINUED
(XSI.) Вернуть сведения о порожденном процессе, который продолжился, если его статус не сообщался с момента изменения. Это также для управления работой. Этот флаг является расширением XSI и не доступен под GNU/Linux.
С заполненным значением
*status
работают несколько макросов, определяющие, что случилось. Они имеют тенденцию образовывать пары: один макрос для определения, что что-то случилось, и если этот макрос истинен, еще один макрос позволяет получить подробности. Макросы следующие:
WIFEXITED(status)
Этот макрос не равен нулю (true), если процесс завершился (в противоположность изменению состояния).
WEXITSTATUS(status)
Этот макрос дает статус завершения; он равен восьми наименее значимым битам значения, переданного
exit()
или возвращенного из main()
. Этот макрос следует использовать лишь если WIFEXIDED(status)
равен true.
WIFSIGNALED(status)
Этот макрос не равен нулю, если процесс подвергся действию завершающего сигнала death-by-signal.
WTERMSIG(status)
Этот макрос предоставляет номер сигнала, который завершил процесс. Этот макрос следует использовать, лишь когда
WIFSIGNALED(status)
равен true.
WIFSTOPPED(status)
Этот макрос не равен нулю, если процесс был остановлен.
WSTOPSIG(status)
Этот макрос предоставляет номер сигнала, который остановил процесс. (Процесс остановить могут несколько сигналов.) Этот макрос следует использовать лишь когда
WIFSTOPPED(status)
равен true. Сигналы управления работами обсуждаются в разделе 10.8.2 «Сигналы управления работой».
WIFCONTINUED(status)
(XSI.) Этот макрос не равен нулю, если процесс был продолжен. Соответствующего макроса
WCONTSIG()
нет, поскольку лишь один сигнал может вызвать продолжение процесса.
Обратите внимание, что этот макрос является расширением XSI и в частности, он недоступен в GNU/Linux. Следовательно, если вы хотите его использовать, заключите код внутри '
#ifdef WIFCONTINUED ... #endif
'.
WCOREDUMP(status)
(Общий.) Этот макрос не равен нулю, если процесс создал снимок. Снимок процесса (core dump) является образом запущенного процесса в памяти, созданном при завершении процесса. Он предназначен для использования впоследствии при отладке. Системы Unix называют файл
core
, тогда как системы GNU/Linux используют corе.pid
, где pid
является ID завершившегося процесса. Определенные сигналы завершают процесс и автоматически создают снимок процесса.
Обратите внимание, что этот макрос не стандартный. Системы GNU/Linux, Solaris и BSD его поддерживают, однако некоторые другие системы Unix нет. Поэтому и здесь, если нужно его использовать, заключите код внутрь '
#ifdef WCOREDUMP ... #endif
'.
Большинство программ не интересуются, почему завершился порожденный процесс; им просто нужно, что он завершился, возможно, отметив, было завершение успешным или нет. Программа GNU Coreutils
install
демонстрирует такое простое использование fork()
, execlp()
и wait()
. Опция -s
заставляет install
запустить для устанавливаемого двоичного исполняемого файла программу strip
. (strip
удаляет из исполняемого файла отладочную и прочую информацию. Это может сохранить значительное пространство. На современных системах с многогигабайтными жесткими дисками при установке редко бывает необходимо использовать strip
для исполняемых файлов.) Вот функция strip()
из install.с
:
513 /* Вырезать таблицу имен из файла PATH.
514 Мы могли бы сначала вытащить из файла магическое число
515 для определения, нужно ли вырезать, но заголовочные файлы и
516 магические числа варьируют от системы к системе так сильно, что
517 сделать его переносимым было бы очень трудно. Не стоит усилий. */
518
519 static void
520 strip (const char *path)
521 {
522 int status;
523 pid_t pid = fork();
524
525 switch (pid)
526 {
527 case -1:
528 error(EXIT_FAILURE, errno, _("fork system call failed"));
529 break;
530 case 0: /* Порожденный. */
531 execlp("strip", "strip", path, NULL);
532 error(EXIT_FAILURE, errno, _("cannot run strip"));
533 break;
534 default: /* Родитель. */
535 /* Родительский процесс. */
536 while (pid != wait(&status)) /* Ждать завершения потомка. */
537 /* Ничего не делать. */ ;
538 if (status)
539 error(EXIT_FAILURE, 0, _("strip failed"));
540 break;
541 }
542 }
Строка 523 вызывает
fork()
. Затем оператор switch
предпринимает нужное действие для возвращения ошибки (строки 527–529), порожденного процесса (строки 530–533) и родительского процесса (строки 534–539).
Стиль строк 536–537 типичен; они ожидают завершения нужного порожденного процесса. Возвращаемое значение wa
it()
является PID этого потомка. Оно сравнивается с PID порожденного процесса, status
проверяется лишь на предмет равенства нулю (строка 538), в случае ненулевого результата потомок завершился неудачно. (Тест, хотя и правильный, грубый, но простой. Более правильным был бы тест наподобие 'if (WIFEXITED(status) && WEXITSTATUS(status) != 0)
'.)
Из описаний и кода, представленных до сих пор, может показаться, что родительские программы должны выбрать определенный момент, чтобы ожидать завершения любого порожденного процесса, возможно, с опросом в цикле (как делает
install.c
), ожидая всех потомков. В разделе 10.8.3 «Родительский надзор: три различные стратегии» мы увидим, что это необязательно. Скорее, сигналы предоставляют ряд механизмов для использования уведомлениями родителей о завершении порожденных процессов.
9.1.6.2. Использование функций BSD: wait3()
и wait4()
Системные вызовы BSD
wait3()
и wait4()
полезны, если вы интересуетесь ресурсами, использованными порожденным процессом. Функции нестандартны (что означает, что они не являются частью POSIX), но широко доступны, в том числе на GNU/Linux. Объявления следующие:
#include /* Обычный */
#include
/* Под GNU/Linux не нужно, но улучшает переносимость */
#include
#include
pid_t wait3(int *status, int options, struct rusage *rusage);
pid_t wait4(pid_t pid, int *status, int options, struct rusage *rusage);
Переменная
status
та же, что и для wait()
и waitpid()
. Все описанные ранее макросы (WIFEXITED()
и т.д.) могут использоваться и с ними.
Значение
options
также то же самое, что и для waitpid()
: либо 0, либо побитовое ИЛИ с одним или обоими флагами WNOHANG
и WUNTRACED
.
wait3()
ведет себя подобно wait()
, получая сведения о первом доступном порожденном зомби, a wait4()
подобна waitpid()
, получая сведения об определенном процессе. Обе функции возвращают PID потомка, -1 при ошибке или 0, если нет доступных процессов и был использован флаг WNOHANG
. Аргумент pid
может принимать те же значения, что и аргумент pid
для waitpid()
.
Ключевым отличием является указатель
struct rusage
. Если он не равен NULL
, система заполняет ее сведениями о процессе. Эта структура описана в POSIX и в справочной странице getrusage(2):
struct rusage {
struct timeval ru_utime; /* используемое время пользователя */
struct timeval ru_stime; /* используемое системное время */
long ru_maxrss; /* максимальный размер резидентного набора */
long ru_ixrss; /* общий размер разделяемой памяти */
long ru_idrss; /* общий размер не разделяемых данных */
long ru_isrss; /* общий размер не разделяемого стека */
long ru_minflt; /* использование страниц */
long ru_majflt; /* ошибок страниц */
long ru_nswap; /* подкачек */
long ru_inblock; /* блочных операций ввода */
long ru_oublock; /* блочных операций вывода */
long ru_msgsnd; /* посланных сообщений */
long ru_msgrcv; /* полученных сообщений */
long ru_nsignals; /* полученных сигналов */
long ru_nvcsw; /* добровольных переключений контекста */
long ru_nivcsw; /* принудительных переключений контекста */
};
Чисто BSD системы (4.3 Reno и более поздние) поддерживают все поля. В табл. 9.2 описаны доступность различных полей
struct rusage
для POSIX и Linux.
Таблица 9.2. Доступность полей
struct rusage
Поле
POSIX
Linux
Поле
POSIX
Linux
ru_utime
√
≥ 2.4
ru_nswap
≥2.4
ru_stime
√
≥2.4
ru_nvcsw
≥2.6
ru_minflt
≥2.4
ru_nivcsw
≥2.6
ru_majflt
≥2.4
Стандартом определены лишь поля, помеченные «POSIX». Хотя Linux определяет полную структуру, ядро 2.4 поддерживает лишь поля времени пользователя и системного времени. Ядро 2.6 поддерживает также поля, связанные с переключением контекста.[92]
Наиболее интересными полями являются
ru_utime
и ru_stime
, использование времени процессора в режиме пользователя и ядра соответственно. (Время процессора в режиме пользователя является временем, потраченным на исполнение кода уровня пользователя. Время процессора в режиме ядра является временем, потраченным в ядре в пользу процесса.)
Эти два поля используют
struct timeval
, которая содержит значения времени с точностью до микросекунд. Дополнительные сведения по этой структуре см. в разделе 14.3.1 «Время в микросекундах: gettimeofday()
».
В 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
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
int setpgid(pid_t pid, pid_t pgid); /* POSIX */
int setpgrp(void); /* XSI */
Функция
setpgrp()
проста: она устанавливает ID группы процесса равной ID процесса. Это создает новую группу процессов в том же сеансе, а вызывающий функцию процесс становится лидером группы процессов.
Функция
setpgid()
предназначена для использования управления заданиями. Она позволяет одному процессу устанавливать группу процесса для другого. Процесс может изменить лишь свой собственный ID группы процессов или ID группы процессов порожденного процесса, лишь если этот порожденный процесс не выполнил еще exec
. Управляющая заданиями оболочка делает этот вызов после fork
как в родительском, так и в порожденном процессах. Для одного из них вызов завершается успехом, и ID группы процессов изменяется. (В противном случае нет способа гарантировать упорядочение, когда родитель может изменить ID группы процессов порожденного процесса до того, как последний выполнит exec
. Если сначала успешно завершится вызов родителя, он может перейти на следующую задачу, такую, как обработка других заданий или управление терминалом.)
При использовании
setpgid() pgid
должна быть группой существующего процесса, которая является частью текущего сеанса, фактически подключая pid
к этой группе процессов. В противном случае pgid
должна равняться pid
, создавая новую группу процессов.
Имеется несколько значений для особых случаев как для
pid
, так и для pgid
:
pid = 0
В данном случае setpgid()
изменяет группу процессов вызывающего процесса на pgid
. Это эквивалентно 'setpgid(getpid(), pgid)
'.
pgid = 0
Это устанавливает ID группы процессов для данного процесса равным его PID. Таким образом, 'setpgid(pid, 0)
' является тем же самым, что и 'setpgid(pid, pid)
'. Это делает процесс с PID, равным pid
, лидером группы процессов.
Во всех случаях лидеры сеанса являются особыми; их PID, ID группы процессов и ID сеанса идентичны, a ID группы процессов лидера не может быть изменена. (ID сеанса устанавливаются посредством
setsid()
, а получаются посредством getsid()
. Это особые вызовы: см. справочные страницы setsid(2) и getsid(2)).
9.3. Базовое межпроцессное взаимодействие: каналы и очереди FIFO
Межпроцессное взаимодействие (Interprocess communication — IPC) соответствует своему названию: это способ взаимодействия для двух отдельных процессов. Самым старым способом IPC на системах Unix является канал (pipe): односторонняя линия связи. Данные, записанные в один конец канала, выходят из другого конца.
9.3.1. Каналы
Каналы проявляют себя как обычные дескрипторы файлов. Без особого разбирательства вы не можете сказать, представляет ли дескриптор файла сам файл или канал. Это особенность; программы, которые читают из стандартного ввода и записывают в стандартный вывод, не должны знать или заботиться о том, что они могут взаимодействовать с другим процессом. Если хотите знать, каноническим способом проверки этого является попытка выполнить с дескриптором '
lseek(fd, 0L, SEEK_CUR)
'; этот вызов пытается отсчитать 0 байтов от текущего положения, т е. операция, которая ничего не делает[94]. Эта операция завершается неудачей для каналов и не наносит никакого вреда другим файлам.
9.3.1.1. Создание каналов
Системный вызов
pipe()
создает канал:
#include /* POSIX */
int pipe(int filedes[2]);
Значение аргумента является адресом массива из двух элементов целого типа,
pipe()
возвращает 0 при успешном возвращении и -1, если была ошибка.
Если вызов был успешным, у процесса теперь есть два дополнительных открытых дескриптора файла. Значение
filedes[0]
является читаемым концом канала, a filedes [1]
— записываемым концом. (Удобным мнемоническим способом запоминания является то, что читаемый конец использует индекс 0, аналогичный дескриптору стандартного ввода 0, а записываемый конец использует индекс 1, аналогичный дескриптору стандартного вывода 1.)
Как упоминалось, данные, записанные в записываемый конец, считываются из читаемого конца. После завершения работы с каналом оба конца закрываются с помощью вызова
close()
. Следующая простая программа, ch09-pipedemo.c
, демонстрирует каналы путем создания канала, записи в него данных, а затем чтения этих данных из него:
1 /* ch09-pipedemo.c --- демонстрация ввода/вывода с каналом. */
2
3 #include
4 #include
5 #include
6
7 /* main --- создание канала, запись в него и чтение из него. */
8
9 int main(int argc, char **argv)
10 {
11 static const char mesg[] = "Don't Panic!"; /* известное сообщение */
12 char buf[BUFSIZ];
13 ssize_t rcount, wcount;
14 int pipefd[2];
15 size_t l;
16
17 if (pipe(pipefd) < 0) {
18 fprintf(stderr, "%s: pipe failed: %s\n", argv[0],
19 strerror(errno));
20 exit(1);
21 }
22
23 printf("Read end = fd %d, write end = fd %d\n",
24 pipefd[0], pipefd[1]);
25
26 l = strlen(mesg);
27 if ((wcount = write(pipefd[1], mesg, 1)) != 1) {
28 fprintf(stderr, "%s: write failed: %s\n", argv[0],
29 strerror(errno));
30 exit(1);
31 }
32
33 if ((rcount = read(pipefd[0], buf, BUFSIZ)) != wcount) {
34 fprintf(stderr, "%s: read failed: %s\n", argv[0],
35 strerror(errno));
36 exit(1);
37 }
38
39 buf[rcount] = '\0';
40
41 printf("Read <%s> from pipe\n", buf);
42 (void)close(pipefd[0]);
43 (void)close(pipefd[1]);
44
45 return 0;
46 }
Строки 11–15 объявляют локальные переменные; наибольший интерес представляет
mesg
, который представляет текст, проходящий по каналу.
Строки 17–21 создают канал с проверкой ошибок; строки 23–24 выводят значения новых дескрипторов файлов (просто для подтверждения, что они не равны 0, 1 или 2)
В строке 26 получают длину сообщения для использования с
write()
. Строки 27–31 записывают сообщение в канал, снова с проверкой ошибок.
Строки 33–37 считывают содержимое канала, опять с проверкой ошибок. Строка 39 предоставляет завершающий нулевой байт, так что прочитанные данные могут использоваться в качестве обычной строки. Строка 41 выводит данные, а строки 42–43 закрывают оба конца канала. Вот что происходит при запуске программы:
$ ch09-pipedemo
Read end = fd 3, write end = fd 4
Read from pipe
Эта программа не делает ничего полезного, но она демонстрирует основы. Обратите внимание, что нет вызовов
open()
или creat()
и что программа не использует три своих унаследованных дескриптора. Тем не менее, write()
и read()
завершаются успешно, показывая, что дескрипторы файлов действительны и что данные, поступающие в канал, действительно выходят из него.[95] Конечно, будь сообщение слишком большим, наша программа не работала бы. Это происходит из-за того, что размер (памяти) каналов ограничен, факт, который мы обсудим в следующем разделе.
Подобно другим дескрипторам файлов, дескрипторы для каналов наследуются порожденным процессом после
fork
, и если они не закрываются, все еще доступны после exec
. Вскоре мы увидим, как использовать это обстоятельство и сделать с каналами что-то интересное.
9.3.1.2. Буферирование каналов
Каналы буферируют свои данные, что означает, что записанные в канал данные хранятся ядром до тех пор, пока не будут прочитаны. Однако, канал может содержать лишь такое-то количество записанных, но еще не прочитанных данных. Мы можем называть записывающий процесс производителем, а читающий процесс потребителем. Как система управляет полными и пустыми каналами?
Когда канал полон, система автоматически блокирует производителя в следующий раз, когда он пытается осуществить запись данных в канал с помощью
write()
. Когда канал освобождается, система копирует данные в канал, а затем позволяет системному вызову write()
вернуться к производителю.
Подобным же образом, если канал пустой, потребитель блокируется в
read()
до тех пор, пока в канале не появятся данные для чтения. (Блокирующее поведение можно отключить; это обсуждается в разделе 9.4.3.4 «Неблокирующий ввод/вывод для каналов и очередей FIFO».)
Когда производитель вызывает на записывающем конце канала
close()
, потребитель может успешно прочесть любые данные, все еще находящиеся в канале. После этого дальнейшие вызовы read()
возвращают 0, указывая на конец файла.
Напротив, если потребитель закрывает читаемый конец,
write()
на записываемом конце завершается неудачей. В частности, ядро посылает производителю сигнал «нарушенный канал», действием по умолчанию для которого является завершение процесса.
Нашей любимой аналогией для каналов является то, как муж и жена вместе моют и сушат тарелки. Один супруг моет тарелки, помещая чистые, но влажные тарелки в сушилку на раковине. Другой супруг вынимает тарелки из сушилки и вытирает их. Моющий тарелки является производителем, сушилка является каналом, а вытирающий является потребителем.[96]
Если вытирающий супруг оказывается быстрее моющего, сушилка становится пустой, и вытирающему приходится ждать, пока не будут готовы новые тарелки. Напротив, если быстрее вытирающий супруг, сушилка наполняется, и моющему приходится ждать, пока она не опустеет, прежде чем помещать в нее тарелки. Это изображено на рис. 9.3.
Рис. 9.3. Синхронизация процессов канала
9.3.2. Очереди FIFO
Для традиционных каналов единственным способом для двух различных программ получить доступ к одному и тому же каналу является наследование дескрипторов файлов. Это означает, что процессы должны быть порожденными от общего родителя или один должен быть предком другого.
Это может быть серьезным ограничением. Многие системные службы запускаются как демоны, отсоединенные долгоживущие процессы. Должен быть способ отправки данных таким процессам (и, возможно, получения данных от них). Файлы для этого не подходят; синхронизация трудна или невозможна, а каналы для выполнения задания не могут быть созданы, поскольку нет общих предков.
Для решения этой проблемы System III предложила идею о FIFO. FIFO,[97] или именованный канал, является файлом в файловой системе, который действует подобно каналу. Другими словами, один процесс открывает FIFO для записи, тогда как другой открывает его для чтения. Затем данные, записанные; в FIFO, читаются читателем. Данные буферируются ядром, а не хранятся на диске.
Рассмотрите спулер печати. Демон спулера управляет физическими принтерами, создавая задания для печати и печатая по одному заданию за раз. Для добавления в очередь задания программное обеспечение принтера на уровне пользователя должно сообщаться с демоном спулера. Одним способом для осуществления этого является создание спулером FIFO с хорошо известным именем файла. Программа пользователя может затем открыть FIFO, записать в него запрос и снова закрыть. Спулер находится в цикле, читая запросы из FIFO и обрабатывая их.
Функция mkfifo() создает файлы FIFO:
#include /* POSIX */
#include
int mkfifo(const char *pathname, mode_t mode);
Аргумент
pathname
является именем создаваемого FIFO, a mode
является данными ему правами доступа, аналогичными второму аргументу функции creat()
или третьему аргументу функции open()
(см. раздел 4.6 «Создание файлов»). Файлы FIFO удаляются, как любые другие, с помощью remove()
или unlink()
(см. раздел 5.1.5.1 «Удаление открытых файлов»).
Справочная страница GNU/Linux mkfifo(3) указывает, что FIFO должен быть открыт как для чтения, так и для записи в одно и то же время, до того, как может быть осуществлен ввод/вывод: «Открытие FIFO для чтения обычно блокирует до тех пор, пока какой-нибудь другой процесс не откроет тот же FIFO для записи, и наоборот». После открытия файла FIFO он действует подобно обычному каналу; т.е. это просто еще один дескриптор файла.
Команда
mkfifo
доставляет этот системный вызов на командный уровень. Это упрощает показ файла FIFO в действии:
$ mkfifo afifo /* Создание файла FIFO */
$ ls -l afifo
/* Показать тип и права доступа, обратите внимание на 'p' впереди */
prw-r--r-- 1 arnold devel 0 Oct 23 15:49 afifo
$ cat < afifo & /* Запустить читателя в фоновом режиме */
[1] 22100
$ echo It was a Blustery Day > afifo /* Послать данные в FIFO */
$ It was a Blustery Day /* Приглашение оболочки, cat выводит данные */
/* Нажмите ENTER, чтобы увидеть статус завершения задания */
[1]+ Done cat
9.4. Управление дескрипторами файлов
На данный момент части загадки почти полностью составлены,
fork()
и exec()
создают процессы и запускают в них программы, pipe()
создает канал, который может использоваться для IPC. Чего до сих пор не хватает, так это способа помещения дескрипторов канала на место стандартных ввода и вывода для производителя и потребителя канала.
Системные вызовы
dup()
и dup2()
, совместно с close()
дают вам возможность поместить (скопировать) открытый дескриптор файла на другой номер. Системный вызов fcntl()
дает вам возможность то же самое и управлять несколькими важными атрибутами открытых файлов.
9.4.1. Дублирование открытых файлов: dup()
и dup2()
Два системных вызова создают копию открытого дескриптора файла:
#include /* POSIX */
int dup(int oldfd);
int dup2(int oldfd, int newfd);
Функции следующие:
int dup(int oldfd)
Возвращает наименьшее значение неиспользуемого дескриптора файла; это копия
oldfd
. dup()
возвращает неотрицательное целое в случае успеха и -1 при неудаче.
int dup2(int oldfd, int newfd)
Делает
newfd
копией oldfd
; если newfd
открыт, он сначала закрывается, как при использовании close()
. dup2()
возвращает новый дескриптор или -1, если была проблема. Помните рис. 9.1, в котором два процесса разделяли общие указатели на один и тот же элемент файла в таблице файлов ядра? dup()
и dup2()
создают ту же ситуацию внутри одного процесса. См. рис. 9.4.
Рис. 9.4. Разделение дескриптора файла как результат '
dup2(1, 3)
'
На этом рисунке процесс выполнил '
dup2(1, 3)
', чтобы сделать дескриптор файла 3-й копией стандартного вывода, дескриптора файла 1. Точно как описано ранее, эти два дескриптора разделяют общее смещение открытого файла.
В разделе 4.4.2 «Открытие и закрытие файлов» мы упомянули, что
open()
(и creat()
) всегда возвращают наименьшее целое значение неиспользуемого дескриптора для открываемого файла. Этому правилу следуют почти все системные вызовы, которые возвращают новые дескрипторы файлов, а не только open()
и creat()
. (dup2()
является исключением, поскольку он предусматривает способ получения конкретного нового дескриптора файла, даже если он не является наименьшим неиспользуемым дескриптором.)
При наличии правила «возвращения наименьшего неиспользуемого номера» в сочетании с функцией
dup()
теперь легко поместить дескрипторы файла канала на место стандартного ввода и вывода. В предположении, что текущим процессом является оболочка и что ей необходимо создать два порожденных процесса для образования двухступенчатого канала, вот эти шаги:
1. Создать канал с помощью
pipe()
. Это должно быть сделано сначала, чтобы два порожденных процесса могли унаследовать дескрипторы открытых файлов.
2. Создать то, что мы называем «левым потомком». Это процесс, стандартный вывод которого идет в канал. В данном процессе сделать следующее:
a. Использовать '
close(pipefd[0])
', поскольку читаемый конец канала в левом потомке не нужен.
b. Использовать '
close(1)
', чтобы закрыть первоначальный стандартный вывод.
c. Использовать '
dup(pipefd[1])
' для копирования записываемого конца канала в дескриптор файла 1.
d. Использовать '
close(pipefd[1])
', поскольку нам не нужны две копии открытого дескриптора.
e. Выполнить
exec
для запускаемой программы.
3. Создать то, что мы называем «правым потомком». Это процесс, стандартный ввод которого поступает из канала. Шаги для этого потомка являются зеркальным отражением шагов для левого потомка:
a. Использовать '
close(pipefd[1])
', поскольку записываемый конец канала в правом потомке не нужен.
b. Использовать '
close(0)
', чтобы закрыть первоначальный стандартный ввод.
c. Использовать '
dup(pipefd[0])
' для копирования читаемого конца канала в дескриптор файла 0.
d. Использовать '
close(pipefd[0])
', поскольку нам не нужны две копии открытого дескриптора.
e. Выполнить
exec
для запускаемой программы.
4. В родителе закрыть оба конца канала — '
close(pipefd[0]); close(pipefd[1])
'.
5. Наконец, использовать в родителе
wait()
для ожидания завершения обоих порожденных процессов.
Обратите внимание, как важно закрыть неиспользуемые копии дескрипторов файлов каналов. Как мы отмечали ранее, файл не закрывается до тех пор, пока не будет закрыт последний открытый для него дескриптор. Это верно, даже если дескрипторы файлов разделяют несколько процессов. Закрытие не использующихся дескрипторов файлов имеет значение, поскольку процесс, читающий из канала, не получит указания конца файла, пока все копии записываемого конца не будут закрыты.
В нашем случае после порождения двух потомков имеются три процесса, у каждого из которых есть копии двух дескрипторов файлов каналов: родительский и два порожденных. Родительский процесс закрывает оба конца, поскольку ему не нужен канал. Левый потомок записывает в канал, поэтому ему нужно закрыть читаемый конец. Правый потомок читает из канала, поэтому ему нужно закрыть записываемый конец. Это оставляет открытым ровно по одной копии дескриптора файла.
Когда левый потомок завершает работу, он заканчивается. Система после этого закрывает все его дескрипторы файлов. Когда это случается, правый потомок получает в конечном счете уведомление конца файла и тоже может завершить работу и выйти.
Следующая программа,
ch09-pipeline.c
, создает эквивалент следующего конвейера оболочки:
$ echo hi there | sed s/hi/hello/g
hello there
Вот программа:
1 /* ch09-pipeline.c --- ответвляет два процесса в их собственный конвейер.
2 Для краткости проверка ошибок сведена к минимуму. */
3
4 #include
5 #include
6 #include
7 #include
8 #include
9
10 int pipefd[2];
11
12 extern void left_child(void), right_child(void);
13
14 /* main --- порождение процессов и ожидание их завершения */
15
16 int main(int argc, char **argv)
17 {
18 pid_t left_pid, right_pid;
19 pid_t ret;
20 int status;
21
22 if (pipe(pipefd) < 0) { /* создать канал в самом начале */
23 perror("pipe");
24 exit(1);
25 }
26
27 if ((left_pid = fork()) < 0) { /* порождение левого потомка */
28 perror("fork");
29 exit(1);
30 } else if (left_pid == 0)
31 left_child();
32
33 if ((right_pid = fork()) < 0) { /* порождение правого потомка */
34 perror("fork");
35 exit(1);
36 } else if (right_pid == 0)
37 right_child();
38
39 close(pipefd[0])); /* закрыть родительские копии канала */
40 close(pipefd[1]);
41
42 while ((ret = wait(&status)) > 0) { /* wait for children */
43 if (ret == left_pid)
44 printf("left child terminated, status: %x\n", status);
45 else if (ret == right_pid)
46 printf("right child terminated, status: %x\n", status);
47 else
48 printf("yow! unknown child %d terminated, status %x\n",
49 ret, status);
50 }
51
52 return 0;
53 }
Строки 22–25 создают канал. Это должно быть сделано в самом начале.
Строки 27–31 создают левого потомка, а строки 33–37 создают правого потомка. В обоих случаях родитель продолжает линейное исполнение ветви
main()
до тех пор, пока порожденный процесс не вызовет соответствующую функцию для манипулирования дескрипторами файла и осуществления exec
.
Строки 39–40 закрывают родительскую копию канала.
Строки 42–50 в цикле ожидают потомков, пока
wait()
не вернет ошибку.
55 /* left_child --- осуществляет работу левого потомка */
56
57 void left_child(void)
58 {
59 static char *left_argv[] = { "echo", "hi", "there", NULL };
60
61 close(pipefd[0]);
62 close(1);
63 dup(pipefd[1]);
64 close(pipefd[1]);
65
66 execvp("echo", left_argv);
67 _exit(errno == ENOENT ? 127 : 126);
68 }
69
70 /* right_child --- осуществляет работу правого потомка */
71
72 void right_child(void)
73 {
74 static char *right_argv[] = { "sed", "s/hi/hello/g", NULL };
75
76 close(pipefd[1]);
77 close(0);
78 dup(pipefd[0]);
79 close(pipefd[0]));
80
81 execvp("sed", right_argv);
82 _exit(errno == ENOENT ? 127 : 126);
83 }
Строки 57–68 являются кодом для левого потомка. Процедура следует приведенным выше шагам, закрывая ненужный конец канала, закрывая первоначальный стандартный вывод, помещая с помощью
dup()
записываемый конец канала на номер 1 и закрывая затем первоначальный записываемый конец. В этот момент строка 66 вызывает execvp()
, и если она завершается неудачей, строка 67 вызывает _exit()
. (Помните, что строка 67 никогда не выполняется, если execvp()
завершается удачно.)
Строки 72–83 делают подобные же шаги для правого потомка. Вот что происходит при запуске:
$ ch09-pipeline /* Запуск программы */
left child terminated, status: 0 /* Левый потомок завершается до вывода (!) */
hello there /* Вывод от правого потомка */
right child terminated, status: 0
$ ch09-pipeline /* Повторный запуск программы */
hello there /* Вывод от правого потомка и ... */
right child terminated, status: 0 /* Правый потомок завершается до левого */
left child terminated, status: 0
Обратите внимание, что порядок, в котором завершаются потомки, не является детерминированным. Он зависит от загрузки системы и многих других факторов, которые могут повлиять на планирование процессов. Вам следует проявить осторожность, чтобы избежать предположений о порядке действий при написании кода, создающего несколько процессов, в особенности для кода, который вызывает семейство функций
wait()
.
Весь процесс показан на рис. 9.5.
Рис. 9.5. Создание конвейера родителем
На рис. 9.5 (а) изображена ситуация после создания родителем канала (строки 22–25) и двух порожденных процессов (строки 27–37).
На рис. 9.5 (b) показана ситуация после закрытия родителем канала (строки 39–40) и начала ожидания порожденных процессов (строки 42–50). Каждый порожденный процесс поместил канал на место стандартного вывода (левый потомок, строки 61–63) и стандартного ввода (строки 76–78).
Наконец, рис. 9.5 (с) изображает ситуацию после закрытия потомками первоначального канала (строки 64 и 79) и вызова
execvp()
(строки 66 и 81).
9.4.2. Создание нелинейных конвейеров: /dev/fd/XX
Многие современные системы Unix, включая GNU/Linux, поддерживают в каталоге
/dev/fd
[98] специальные файлы. Эти файлы представляют дескрипторы открытых файлов с именами /dev/fd/0
, /dev/fd/1
и т.д. Передача такого имени функции open()
возвращает новый дескриптор файла, что в сущности является тем же самым, что и вызов dup()
для данного номера дескриптора.
Эти специальные файлы находят свое применение на уровне оболочки: Bash,
ksh88
(некоторые версии) и ksh93
предоставляют возможность замещения процесса (process substitution), что позволяет создавать нелинейные конвейеры. На уровне оболочки для входного конвейера используется запись '<(...)
', а для выходного конвейера запись '>(...)
'. Например, предположим, вам нужно применить команду diff
к выводу двух команд. Обычно вам пришлось бы использовать временные файлы:
command1 > /tmp/out.$$.1
command2 > /tmp/out.$$.2
diff /tmp/out.$$.1 /tmp/out.$$.2
rm /tmp/out.$$.1 /tmp/out.$$.2
С замещением процессов это выглядит следующим образом:
diff <(command1) <(command2)
Не надо никаких беспорядочных файлов для временного запоминания и удаления. Например, следующая команда показывает, что наш домашний каталог является ссылкой на другой каталог:
$ diff <(pwd) <(/bin/pwd)
1c1
< /home/arnold/work/prenhall/progex
---
> /d/home/arnold/work/prenhall/progex
Незамысловатая команда
pwd
является встроенной в оболочку: она выводит текущий логический путь, который управляется оболочкой с помощью команды cd
. Программа /bin/pwd
осуществляет обход физической файловой системы для вывода имени пути.
Как выглядит замещение процессов? Оболочка создает вспомогательные команды[99] ('
pwd
' и '/bin/pwd
'). Выход каждой из них подсоединяется к каналу, причем читаемый конец открыт в дескрипторе нового файла для главного процесса ('diff
'). Затем оболочка передает главному процессу имена файлов в /dev/fd
в качестве аргументов командной строки. Мы можем увидеть это, включив в оболочке трассировку исполнения.
$ set -х /* Включить трассировку исполнения */
$ diff <(pwd) <(/bin/pwd) /* Запустить команду */
+ diff /dev/fd/63 /dev/fd/62 /* Трассировка оболочки: главная,
программа, обратите внимание на аргументы */
++ pwd /* Трассировка оболочки: вспомогательные программы */
++ /bin/pwd
1c1 /* Вывод diff */
< /home/arnold/work/prenhall/progex
---
> /d/home/arnold/work/prenhall/progex
Это показано на рис. 9.6.
Рис. 9.6. Замещение процесса
Если на вашей системе есть
/dev/fd
, вы также можете использовать преимущества этой возможности. Однако, будьте осторожны и задокументируйте то, что вы делаете. Манипуляции с дескриптором файла на уровне С значительно менее прозрачны, чем соответствующие записи оболочки!
9.4.3. Управление атрибутами файла: fcntl()
Системный вызов
fcntl()
(«управление файлом») предоставляет контроль над различными атрибутами либо самого дескриптора файла, либо лежащего в его основе открытого файла. Справочная страница GNU/Linux fcntl(2) описывает это таким способом:
#include /* POSIX */
#include
int fcntl (int fd, int cmd);
int fcntl(int fd, int cmd, long arg);
int fcntl(int fd, int cmd, struct flock *lock);
Другими словами, функция принимает по крайней мере два аргумента; в зависимости от второго аргумента, она может принимать и третий аргумент.
Последняя форма, в которой третий аргумент является указателем на
struct flock
, предназначена для блокировки файла. Блокировка файлов сама по себе представляет большую тему; мы отложим обсуждение до раздела 14.2 «Блокировка файлов».
9.4.3.1. Флаг close-on-exec
После вызова
fork()
и перед вызовом exec()
следует убедиться, что новая программа наследует лишь те открытые файлы, которые ей нужны. Вы не захотите, чтобы порожденный процесс мешался в открытых файлах родителя, если только это так не задумано. С другой стороны, если у родителя множество открытых файлов, это будет искусственно ограничивать число новых файлов, которые может открыть порожденный процесс. (См. сопроводительную врезку.)
Организационно такое поведение может представлять проблему. Часть вашей программы, порождающая новый процесс, не должна особенно нуждаться в других частях программы, манипулирующей открытыми файлами. И цикл наподобие следующего неприятный, поскольку может не быть открытых файлов:
int j;
for (j = getdtablesize(); j >= 3; j--) /* закрыть все, кроме 0, 1, 2 */
(void)close(j);
Решением является флаг close-on-exec (закрытие при исполнении exec). Он является атрибутом самого дескриптора файла, а не лежащего в его основе открытого файла. Когда этот флаг установлен, система автоматически закрывает файл, когда процесс осуществляет
exec
. Установив этот флаг сразу после открытия файла, вам не нужно беспокоиться о том, что какой-нибудь порожденный процесс случайно его унаследует. (Оболочка автоматически устанавливает этот флаг для всех дескрипторов файлов, которые она открывает, начиная с номера 3 и выше.)
Аргумент
cmd
имеет два значения, относящиеся к флагу close-on-exec:
F_GETFD
Получает флаги дескриптора файла. Возвращаемое значение является значением всех установленных флагов дескриптора или -1 при ошибке.
F_SETFD
Устанавливает флаги дескриптора файла в содержащееся в
arg
(третий аргумент) значение. Возвращаемое значение равно 0 при успехе или -1 при ошибке.
В настоящий момент определен лишь один «флаг дескриптора файла»:
FD_CLOEXEC
. Эта именованная константа является нововведением POSIX[100], а большая часть кода использует просто 1 или 0:
if (fcntl(fd, F_SETFD, 1) < 0) ...
/* установить close-on-exec, обработать ошибки */
if (fcntl(fd, F_GETFD) == 1) ...
/* бит close-on-exec уже установлен */
Однако, определение POSIX допускает дальнейшее расширение, поэтому правильный способ написания такого кода больше соответствует этим строкам:
int fd;
long fd_flags;
if ((fd_flags = fcntl(fd, F_GETFD)) < 0) /* Получить флаги */
/* обработать ошибки */
fd_flags |= FD_CLOEXEC; /* Add close-on-exec flag */
if (fcntl(fd, F_SETFD, fd_flags) < 0) /* Установить флаги */
/* обработать ошибки */
ЗАМЕЧАНИЕ. Флаг close-on-exec является собственностью дескриптора, а не лежащего в его основе файла. Поэтому новый дескриптор, возвращенный функциями
dup()
или dup2()
(или fcntl()
с F_DUPD
, которую мы намереваемся посмотреть), не наследует установки флага close-on-exec первоначального дескриптора. Если вам нужно установить его также и для нового дескриптора файла, вы должны не забыть сделать это сами. Такое поведение имеет смысл: если вы просто вызвали dup()
, копируя один конец канала в 0 или 1, вы не захотите, чтобы система закрыла его вместо вас, как только процесс осуществит exec!
История борьбы close-on-exec от gawk
В языке awk операторы ввода/вывода используют обозначение перенаправления, сходное с обозначением для оболочки. Это включает односторонние каналы к и от подпроцесса:
print "something brilliant" > "/some/file" /* Вывод в файл */
getline my_record < "/some/other/file" /* Ввод из файла */
print "more words of wisdom" | "a_reader process" /* Вывод в подпроцесс */
"a_write_process" | getline some_input /* Ввод из подпроцесса */
У интерпретатора
awk
есть дескрипторы открытых файлов для всех перенаправлений файлов, а для обозначений каналов, создающих подпроцессы, интерпретатор awk
создает канал, а затем осуществляет fork
и exec
оболочки для запуска команды, приведенной в строке.
Теперь на современных системах часть стартового кода библиотеки С времени исполнения (который запускается до вызова
main()
) нуждается для управления использованием разделяемых библиотек во временно открытых файлах. Это означает, что для новой программы после исполнения exec
должны быть по крайней мере один или два неиспользуемых дескриптора файла, иначе программа просто не будет работать
Однажды один пользователь сообщил, что когда в программе было максимальное количество открытых файлов, ни один процесс, для которого она пыталась использовать для конвейера
fork
и exec
, не мог успешно начаться!
Вы, возможно, можете догадаться, что произошло. Порожденная оболочка унаследовала дескрипторы открытых файлов, которые
gawk
сама использовала для своих перенаправлений. Мы модифицировали gawk
так, чтобы установить флаг close-on-exec для всех перенаправлений файлов и каналов, что и решило проблему.
9.4.3.2. Дублирование дескриптора файла
Когда аргумент
cmd
функции fcntl()
равен F_DUPFD
, ее поведение похоже, но не идентично поведению dup2()
. В этом случае arg
является дескриптором файла, представляющим наименьшее приемлемое значение для нового дескриптора файла:
int new_fd = fcntl(old_fd, F_DUPFD, 7);
/* Возвращаемое значение между 7 и максимумом или неудача */
int new_fd = dup2(old_fd, 7);
/* Возвращаемое значение 7 или неудача */
Вы можете имитировать поведение
dup()
, которая возвращает наименьший свободный дескриптор файла, использовав 'fcntl(old_fd, F_DUPED, 0)
'.
Если вы помните, что дескрипторы файлов являются просто индексами внутренней таблицы, работа этой функции должна быть ясна. Третий аргумент просто предоставляет индекс, с которого ядро должно начать поиск неиспользуемого дескриптора файла.
Использовать ли в собственном коде
fcntl()
с F_DUPED
или dup()
или dup2()
, в значительной степени является делом вкуса. Все три функции API являются частью POSIX и широко поддерживаются. У нас легкое пристрастие к dup()
и dup2()
, поскольку они более специфичны в своих действиях, поэтому являются самодокументирующимися. Но поскольку все они довольно просты, эта аргументация может вас не убедить.
9.4.3.3. Работа с флагами статуса файла и режимами доступа
В разделе 4.6.3 «Возвращаясь к
open()
» мы предоставили полный список флагов O_xx, которые принимает open()
. POSIX разбивает их по функциям, классифицируя в соответствии с табл. 9.4.
Таблица 9.4. Флаги O_xx для
open()
, creat()
и fcntl()
Категория
Функции
Флаги
Доступ к файлу
open()
, fcntl()
O_RDONLY
, O_RDWR
, O_WRONLY
Создание файла
open()
O_CREAT
, O_EXCL
, O_NOCTTY
, O_TRUNC
Статус файла
open()
, fcntl()
O_APPEND
, O_DSYNC
, O_NONBLOCK
, O_RSYNC
, O_SYNC
Помимо первоначальной установки различных флагов с помощью
open()
, вы можете использовать fcntl()
для получения текущих установок, а также их изменения. Это осуществляется с помощью значений cmd
F_GETFL
и F_SETFL
соответственно. Например, вы можете использовать эти команды для изменения установки неблокирующего флага, O_NONBLOCK
, подобным образом:
int fd_flags;
if ((fd_flags = fcntl(fd, F_GETFL)) < 0)
/* обработать ошибку */
if ((fd_flags & O_NONBLOCK) != 0) { /* Установлен неблокирующий флаг */
fd_flags &= ~O_NONBLOCK; /* Сбросить его */
if (fcntl(fd, F_SETFL, fd_flags) != 0) /* Дать ядру новое значение */
/* обработать ошибку */
}
Помимо самих режимов именованная константа
O_ACCMODE
является маской, которую вы можете использовать для выделения из возвращаемого значения режимов прав доступа.
fd_flags = fcntl(fd, F_GETFL);
switch (fd_flags & O_ACCESS) {
case O_RDONLY:
/* ...действия только для чтения... */
break;
case O_WRONLY:
/* ...действия только для записи... */
break;
case O_RDWR:
/* ...действия для чтения и записи... */
break;
}
POSIX требует, чтобы
O_RDONLY
, O_RDWR
и O_WRONLY
были побитово различными, таким образом, гарантируется, что код, подобный только что показанному, будет работать и является простым способом определения того, как был открыт произвольный дескриптор файла.
Используя
F_SETFL
вы можете также изменить эти режимы, хотя по-прежнему применяется проверка прав доступа. Согласно справочной странице GNU/Linux fcnlt(2) флаг O_APPEND
не может быть сброшен, если он использовался при открытии файла.
9.4.3.4. Неблокирующий ввод/вывод для каналов и FIFO
Ранее для описания способа работы каналов мы использовали сравнение с двумя людьми, моющими и вытирающими тарелки с использованием сушилки; когда сушилка заполняется, останавливается моющий, а когда она пустеет, останавливается вытирающий. Это блокирующее поведение: производитель или потребитель блокируются в вызове
write()
или read()
, ожидая либо освобождения канала, либо появления в нем данных.
В действительности человек, ожидающий опустения или заполнения сушилки, не должен просто неподвижно стоять.[101] Вместо этого незанятый супруг мог бы пойти и найти другую работу по кухне (такую, как подметание всех крошек за детьми на полу), пока сушилка снова не будет готова.
На языке Unix/POSIX эта концепция обозначается термином неблокирующий ввод/вывод, т.е. запрошенный ввод/вывод либо завершается, либо возвращает значение ошибки, указывающее на отсутствие данных (для читающего) или отсутствие места (для записывающего). Неблокирующий ввод/вывод применяется к каналам и FIFO, а не к обычным файлам на диске. Он может применяться также и к определенным устройствам, таким как терминалы, и к сетевым соединениям, обе эти темы выходят за рамки данной книги.
С функцией
open()
может использоваться флаг O_NONBLOCK
для указания неблокирующего ввода/вывода, он может быть установлен и сброшен с помощью fcntl()
. Для open()
и read()
неблокирующий ввод/вывод прост.
Открытие FIFO с установленным или сброшенным
O_NONBLOCK
демонстрирует следующее поведение:
open("/fifо/file", O_RDONLY, mode)
Блокируется до открытия FIFO для записи.
open("/fifo/file", O_RDONLY | O_NONBLOCK, mode)
Открывает файл, возвращаясь немедленно.
open("/fifo/file", O_WRONLY, mode)
Блокирует до открытия FIFO для чтения.
open("/fifo/file", O_WRONLY | O_NONBLOCK, mode)
Если FIFO был открыт для чтения, открывает FIFO и немедленно возвращается. В противном случае возвращает ошибку (возвращаемое значение -1 и
errno
установлен в ENXIO
).
Как описано для обычных каналов, вызов
read()
для FIFO, который больше не открыт для чтения, возвращает конец файла (возвращаемое значение 0). Флаг O_NONBLOCK
в данном случае неуместен. Для пустого канала или FIFO (все еще открытых для записи, но не содержащих данных) все становится интереснее:
read(fd, buf, count) и сброшенный O_NONBLOCK
Функция
read()
блокируется до тех пор, пока в канал или FIFO не поступят данные.
read(fd, buf, count) и установленный O_NONBLOCK
Функция
read()
немедленно возвращает -1 с установленным в errno EAGAIN
.
В заключение, поведение
write()
более сложно. Для обсуждения этого нам нужно сначала представить концепцию атомарной записи. Атомарная запись — это такая запись, при которой все данные записываются целиком, не чередуясь с данными от других записей. POSIX определяет в
константу PIPE_BUF
. Запись в канал или FIFO данных размером менее или равным PIPE_BUF
байтов либо успешно завершается, либо блокируется в соответствии с подробностями, которые мы скоро приведем. Минимальным значением для PIPE_BUF
является _POSIX_PIPE_BUF
, что равняется 512. Само значение PIPE_BUF
может быть больше; современные системы GLIBC определяют ее размер в 4096, но в любом случае следует использовать эту именованную константу и не ожидать, что PIPE_BUF
будет иметь то же значение на разных системах.
Во всех случаях для каналов и FIFO
write()
добавляет данные в конец канала. Это происходит от того факта, что у каналов нет файловых смещений: в них нельзя осуществлять поиск.
Также во всех случаях, как упоминалось, записи размером вплоть до
PIPE_BUF
являются атомарными: данные не перемежаются с данными от других записей. Данные записи размером более PIPE_BUF
байтов могут перемежаться с данными других записей в произвольных границах. Это последнее означает, что вы не можете ожидать, что каждая порция размером PIPE_BUF
большого набора данных будет записана атомарно. Установка O_NONBLOCK
не влияет на это правило.
Как и в случае с
read()
, когда O_NONBLOCK
не установлен, write()
блокируется до тех пор, пока все данные не будут записаны.
Наиболее все усложняется, когда установлен
O_NONBLOCK
. Канал или FIFO ведут себя следующим образом:
размер ≥ nbytes
размер < abytes
nbytes ≤ PIPE_BUF
write()
успешнаwrite()
возвращает (-1)/EAGAIN
размер > 0
размер = 0
nbytes > PIPE_BUF
write()
записывает, что можетwrite()
возвращает (-1)/EAGAIN
Для файлов, не являющихся каналами и FIFO и к которым может быть применен
O_NONBLOCK
, поведение следующее:
размер > 0
write()
записывает, что может
размер = 0
write()
возвращает -1/EAGAIN
Хотя есть ряд сбивающих с толку изменений поведения в зависимости от того, канал это или не канал, установлен
O_NONBLOCK
или сброшен, есть в канале место для записи или нет, а также в зависимости от размера предполагаемой записи, эти правила предназначены для упрощения программирования:
• Всегда можно отличить конец файла:
read()
возвращает 0 байтов.
• Если нет доступных для чтения данных,
read()
либо завершается успешно, либо возвращает указание «нет данных для чтения»: EAGAIN
, что означает «попытайтесь снова позже».
• Если для записи нет места,
write()
либо блокируется до успешного завершения (O_NONBLOCK
сброшен), либо завершается неудачей с ошибкой «в данный момент нет места для записи»: EAGAIN
.
• Когда место есть, будет записано столько данных, сколько возможно, так что в конечном счете все данные будут переписаны.
Подводя итог, если вы собираетесь использовать неблокирующий ввод/вывод, любой код, который использует
write()
, должен быть способен обработать укороченную запись, когда успешно записан меньший объем данных, чем было затребовано. Устойчивый код в любом случае должен быть написан таким способом: даже в случае обычного файла диск может оказаться заполненным и write()
сможет записать лишь часть данных.
Более того, вы должны быть готовы обработать
EAGAIN
, понимая, что в этом случае неудача write()
не обязательно означает фатальную ошибку. То же верно для кода, использующего для чтения неблокирующий ввод/вывод: признайте, что и здесь EAGAIN
не является фатальным. (Однако, может стоит подсчитывать число таких отказов, оставив попытки, когда их слишком много.)
Неблокирующий ввод/вывод действительно усложняет вашу жизнь, в этом нет никакого сомнения. Но для многих приложений он является необходимостью, позволяющей выполнить задание. Снова рассмотрите спулер печати. Демон спулера не может позволить себе находиться в блокирующем
read()
для файла FIFO, которому представлены входящие задания. Он должен иметь также возможность отслеживать запущенные задания и, возможно, периодически проверять состояние печатающих устройств (например, убедиться, что не заело бумагу).
9.4.3.5. Сводка fcntl()
Сводка для системного вызова
fcntl()
приведена в табл. 9.5.
Таблица 9.5. Сводка
fcntl()
Значение cmd
Значение arg
Возвращает
F_DUPFD
Наименьший новый дескриптор
Дублирует аргумент fd
F_GETFD
Получает флаги дескриптора файла (close-on-exec)
F_SETFD
Новое значение флага
Устанавливает флаги дескриптора файла (close-on-exec)
F_GETFL
Получает флаги основного файла
F_SETFL
Новое значение флага
Устанавливает флаги основного файла
Флаги создания, статуса и прав доступа файла копируются, когда дескриптор файла дублируется. Флаг close-on-exec не копируется.
9.5. Пример: двусторонние каналы в gawk
Двусторонний канал соединяет два процесса двунаправленным образом. Обычно, по крайней мере для одного из процессов, на канал с другим процессом настраиваются как стандартный ввод, так и стандартный вывод. Оболочка Корна (
ksh
) ввела двусторонние каналы на уровне языка, обозначив термином сопроцесса (coprocess):
команды и аргументы движка базы данных |& /* Запустить сопроцесс в фоновом режиме */
print -p "команда базы данных" /* Записать в сопроцесс */
read -p db_response /* Прочесть из сопроцесса */
Здесь движок базы данных представляет любую серверную программу, которая может управляться интерфейсной частью, в данном случае, сценарием
ksh
. У движка базы данных стандартный ввод и стандартный вывод подсоединены к оболочке посредством двух отдельных односторонних каналов.[102] Это показано на рис. 9.7.
Рис. 9.7. Сопроцессы оболочки Корна
В обычном
awk
каналы к или от подпроцесса являются односторонними: нет способа послать данные в программу и прочесть посланные от нее в ответ данные — нужно использовать временный файл. GNU awk
(gawk
) заимствует обозначение '|&
' от ksh
для расширения языка awk
:
print "команда" |& "движок базы данных" /* Запустить сопроцесс, записать в него */
"движок базы данных" |& getline db_response /* Прочесть из сопроцесса */
gawk
использует запись '|&
' также для сокетов TCP/IP и порталов BSD, которые не рассматриваются в данной книге. Следующий код из io.c
в дистрибутиве gawk
3.1.3 является частью функции two_way_open()
, которая устанавливает простой сопроцесс: она создает два канала, порождает новый процесс и осуществляет все манипуляции с дескриптором файла. Мы опустили ряд не относящихся к делу частей кода (эта функция занимает больше места, чем следовало бы):
1561 static int
1562 two_way_open(const char *str, struct redirect *rp)
1563 {
...
1827 /* случай 3: двусторонний канал с порожденным процессом */
1828 {
1829 int ptoc[2], сtop[2];
1830 int pid;
1831 int save_errno;
1835
1836 if (pipe(ptoc) < 0)
1837 return FALSE; /* установлен errno, диагностика от вызывающего */
1838
1839 if (pipe(ctop) < 0) {
1840 save_errno = errno;
1841 close(ptoc[0]);
1842 close(ptoc[1]);
1843 errno = save_errno;
1844 return FALSE;
1845 }
Первым шагом является создание двух каналов,
ptoc
является каналом «от родителя к потомку», а ctop
— «от потомка к родителю». Во время чтения держите в уме, что индекс 0 является читаемым концом, а 1 — записываемым.
Строки 1836–1837 создают первый канал,
ptoc
. Строки 1839–1845 создают второй канал, закрывая при неудачном создании и первый. Это важно. Небрежность в закрытии открытых, но не используемых каналов ведет к утечкам дескрипторов файлов. Как и память, дескрипторы файлов являются конечным ресурсом, и когда они иссякают, то теряются.[103] То же верно и для открытых файлов: убедитесь, что ваш обрабатывающий ошибки код всегда закрывает все открытые файлы и каналы, которые не нужны, когда происходит ошибка.
save_errno
сохраняет значения errno
, установленные pipe()
, на тот редкий случай, когда close()
может завершиться неудачей (строка 1840). Затем errno
восстанавливается в строке 1843.
1906 if ((pid = fork()) < 0) {
1907 save_errno = errno;
1908 close(ptoc[0]); close(ptoc[1]);
1909 close(ctop[0]); close(ctop[1]);
1910 errno = save_errno;
1911 return FALSE;
1912 }
Строки 1906–1912 порождают процесс, на этот раз закрывая оба канала, если
fork()
потерпит неудачу. Здесь также первоначальное значение errno
сохраняется и восстанавливается для последующего использования при диагностике.
1914 if (pid == 0) { /* порожденный процесс */
1915 if (close(1) == -1)
1916 fatal(_("close of stdout in child failed (%s)"),
1917 strerror(errno));
1918 if (dup(ctop[1]) != 1)
1919 fatal(_{"moving pipe to stdout in child failed (dup: %s)"), strerror(errno));
1920 if (close(0) == -1)
1921 fatal(_("close of stdin in child failed (%s)"),
1922 strerror(errno));
1923 if (dup(ptoc[0]) != 0)
1924 fatal(_("moving pipe to stdin in child failed (dup: %s)"), strerror(errno));
1925 if (close(ptoc[0]) == -1 || close(ptoc[1]) == -1
1926 || close(ctop[0]) == -1 || close(ctop[1]) == -1)
1927 fatal(_("close of pipe failed (%s)"), strerror(errno));
1928 /* stderr HE дублируется в stdout потомка */
1929 execl("/bin/sh", "sh", "-c", str, NULL);
1930 _exit(errno == ENOENT ? 127 : 126);
1931 }
Строки 1914–1931 обрабатывают код потомка, с соответствующей проверкой ошибок и сообщениями на каждом шагу. Строка 1915 закрывает стандартный вывод. Строка 1918 копирует записываемый конец канала от потомка к родителю на 1. Строка 1920 закрывает стандартный ввод, а строка 1923 копирует читаемый конец канала от родителя к потомку на 0. Если это все работает, стандартные ввод и вывод теперь на месте и подключены к родителю.
Строки 1925–1926 закрывают все четыре первоначальные дескрипторы файлов каналов, поскольку они больше не нужны. Строка 1928 напоминает нам, что стандартная ошибка остается на месте. Это лучшее решение, поскольку пользователь увидит ошибки от сопроцесса. Программа
awk
, которая должна перехватить стандартную ошибку, может использовать в команде обозначение '2>&1
' для перенаправления стандартной ошибки сопроцесса или записи в отдельный файл.
Наконец, строки 1929–1930 пытаются запустить для оболочки
execl()
и соответственно выходят, если это не удается.
1934 /* родитель */
1935 rp->pid = pid;
1936 rp->iop = iop_alloc(ctop[0], str, NULL);
1937 if (rp->iop == NULL) {
1938 (void)close(ctop[0]);
1939 (void)close(ctop[1]);
1940 (void)close(ptoc[0]);
1941 (void)close(ptoc[1]);
1942 (void)kill(pid, SIGKILL); /* overkill? (pardon pun) */
1943
1944 return FALSE;
1945 }
Первым шагом родителя является настройка входного конца от сопроцесса. Указатель
rp
указывает на struct redirect
, которая содержит поле для сохранения PID порожденного процесса, FILE*
для вывода и указатель IOBUF*
с именем iop
. IOBUF
является внутренней структурой данных gawk
для осуществления ввода. Она, в свою очередь, хранит копию нижележащего дескриптора файла.
Строка 1935 сохраняет значение ID процесса. Строка 1936 выделяет память для новой
IOBUF
для данных дескриптора файла и командной строки. Третий аргумент здесь равен NULL
: он позволяет при необходимости использовать предварительно выделенный IOBUF
.
Если выделение памяти потерпело неудачу, строки 1937–1942 производят очистку, закрывая каналы и посылая сигнал «kill» порожденным процессам, чтобы заставить их завершить работу. (Функция
kill()
описана в разделе 10.6.7 «Отправка сигналов kill()
и killpg()
».)
1946 rp->fp = fdopen(ptoc[1], "w");
1947 if (rp->fp == NULL) {
1948 iop_close(rp->iop);
1949 rp->iop = NULL;
1950 (void)close(ctop[0]);
1951 (void)close(ctop[1]);
1952 (void)close(ptoc[0]);
1953 (void)close(ptoc[1]);
1954 (void)kill(pid, SIGKILL); /* избыточно? (пардон, каламбур)
[104] */
1955
1956 return FALSE;
1957 }
Строки 1946–1957 аналогичны. Они устанавливают вывод родителя на потомка, сохраняя дескриптор файла для записывающего конца канала от родителя к потомку в
FILE*
, используя функцию fdopen()
. Если это завершается неудачей, строки 1947–1957 предпринимают те же действия, что и ранее: закрывают все дескрипторы каналов и посылают сигнал порожденным процессам.
С этого момента записываемый конец канала от родителя к потомку и читаемый конец канала от потомка к родителю хранятся в более крупных структурах:
FILE*
и IOBUF
соответственно. Они автоматически закрываются обычными процедурами, которые закрывают эти структуры. Однако, остаются две задачи:
1960 os_close_on_exec(ctop[0], str, "pipe", "from");
1961 os_close_on_exec(ptoc[1], str, "pipe", "from");
1962
1963 (void)close(ptoc[0]);
1964 (void)close(ctop[1]);
1966
1967 return TRUE;
1968 }
...
1977 }
Строки 1960–1961 устанавливают флаг close-on-exec для двух дескрипторов, которые остались открытыми.
os_close_on_exec()
является простой функцией-оболочкой, которая выполняет эту работу на Unix- и POSIX-совместимых системах, но ничего не делает на системах, в которых нет флага close-on-exec. Это скрывает проблему переносимости в одном месте и позволяет избежать в коде множества запутывающих #ifdef
здесь и в других местах io.c
.
Наконец, строки 1963–1964 закрывают концы каналов, которые не нужны родителю, а строка 1967 возвращает TRUE для обозначения успеха.
9.6. Рекомендуемая литература
Управление заданиями сложно, включает группы процессов, сеансы, механизмы ожидания, сигналы и манипулирование группой процессов терминала. По существу, мы решили не вдаваться в детали. Однако, вы можете захотеть взглянуть на следующие книги:
1. Advanced Programming in the UNIX Environment, 2nd edition, by W. Richard Stevens and Stephen Rago. Addison-Wesley, Reading Massachusetts, USA, 2004. ISBN: 0-201-43307-9.
Эта книга и полна, и основательна, охватывая элементарное и продвинутое программирование под Unix. Она превосходно освещает группы процессов, сеансы, управление заданиями и сигналы
2. The Design and Implementation of the 4.4 BSD Operating System, by Marshall Kirk McKusick, Keith Bostic, Michael J. Karels, and John S. Quarterman. Addison-Wesley, Reading, Massachusetts, USA, 1996. ISBN: 0-201-54979-4.
Эта книга дает хороший обзор того же материала, включая обсуждение структур данных ядра, которое можно найти в разделе 4.8 этой книги.
9.7. Резюме
• Новые процессы создаются с помощью
fork()
. После этого оба процесса исполняют один и тот же код, причем единственным различием является возвращаемое значение: 0 в порожденном процессе и положительный номер PID в родительском. Порожденный процесс наследует копии почти всех атрибутов родителя, наиболее важными из которых являются, пожалуй, открытые файлы.
• Унаследованные разделяемые дескрипторы файлов делают возможным многое из высокоуровневой семантики Unix и элегантные управляющие структуры оболочки. Это одна из наиболее фундаментальных частей оригинального дизайна Unix. Из-за разделения дескрипторов файл на самом деле не закрывается до тех пор, пока не будет закрыт последний открытый дескриптор файла. Это в особенности касается каналов, но затрагивает также освобождение дисковых блоков для удаленных, но все еще открытых файлов.
• Вызовы
getpid()
и getppid()
возвращают ID текущего и родительского процессов соответственно. Родителем процесса, первоначальный родитель которого завершается, становится специальный процесс init
с PID 1. Таким образом, PPID может меняться, и приложения должны быть готовы к этому.
• Системный вызов
nice()
дает возможность настраивать приоритет вашего процесса. Чем приятнее вы по отношению к другим процессам, тем меньше ваш относительный приоритет, и наоборот. Лишь суперпользователь может иметь больший приоритет по сравнению с другими процессами. На современных системах, особенно однопользовательских, нет действительных причин для изменения знамения относительного приоритета.
• Системный вызов
exec()
начинает исполнение новой программы в существующем процессе. Шесть различных версий вызова предоставляют гибкость в установке списков аргументов и окружения ценой первоначальной путаницы по поводу того, какую из них лучше всего использовать. Два варианта имитируют механизм поиска оболочки и отступают к использованию оболочки для интерпретации файла в случае, если он не является двоичным исполняемым файлом; эти варианты должны использоваться с предусмотрительностью.
• Значение
argv[0]
для новой программы обычно происходит от имени исполняемого файла, но это лишь соглашение. Как и в случае с fork()
, значительный, но не идентичный набор атрибутов наследуется через exec
. Другие атрибуты сбрасываются для использования подходящих значений по умолчанию.
• Функция
atexit()
регистрирует функции обратного вызова для вызова в порядке LIFO при завершении программы. Функции exit()
, _exit()
и _Exit()
все завершают программу, передавая статус завершения обратно родителю, exit()
очищает открытые потоки FILE*
и запускает функции, зарегистрированные с помощью atexit()
. Две другие функции завершаются немедленно и должны использоваться, лишь когда exec
в порожденном процессе завершилась неудачей. Возвращение из main()
подобно вызову exit()
с данным возвращаемым значением. В C99 и C++ выпадение из main()
в конце функции дает тот же результат, что и 'exit(0)
', но является плохой практикой.
•
wait()
и waitpid()
являются функциями POSIX для получения статуса завершения порожденного процесса. Различные макросы позволяют определить, завершился ли порожденный процесс нормально, и в таком случае определить статус его завершения, или же порожденный процесс претерпел сигнал завершения, и в этом случае определить совершивший этот проступок сигнал. Со специальными опциями waitpid()
предоставляет также сведения о потомках, которые не завершились, но изменили состояние.
• Системы GNU/Linux и большинство Unix-систем поддерживают также функции BSD
wait3()
и wait4()
. GNU/Linux поддерживает также выходящий из употребления union wait
. Функции BSD предоставляют struct rusage
, давая доступ к сведениям об использовании времени процессора, что может быть удобным. Хотя если waitpid()
будет достаточной, то это наиболее переносимый способ выполнения.
• Группы процессов являются частью более крупного механизма управления заданиями, который включает сигналы, сеансы и манипулирование состоянием терминала,
getpgrp()
возвращает ID группы процессов текущего процесса, a getpgid()
возвращает PGID определенного процесса. Сходным образом, setpgrp()
устанавливает PGID текущего процесса равным его PID, делая его лидером группы процессов; setpgid()
дает возможность родительскому процессу установить PGID порожденного, который еще не выполнил exec
.
• Каналы и FIFO предоставляют односторонний коммуникационный канал между двумя процессами. Каналы должны быть установлены общим предком, тогда как FIFO могут использоваться любыми двумя процессами. Каналы создаются с помощью
pipe()
, а файлы FIFO создаются с помощью mkfifo()
. Каналы и FIFO буферируют свои данные, останавливая производителя или потребителя, когда канал заполняется или пустеет.
•
dup()
и dup2()
создают копии дескрипторов открытых файлов. В сочетании с close()
они дают возможность поместить дескрипторы файлов на место стандартного ввода и вывода для каналов. Чтобы каналы работали правильно, все копии неиспользуемых концов каналов до исполнения программой назначения exec должны быть закрыты. Для создания нелинейных каналов может быть использован /dev/fd
, что демонстрируется возможностью замещения процессов оболочками Bash и Korn.
•
fcntl()
является функцией для выполнения различных работ. Она управляет атрибутами как самого дескриптора файла, так и лежащего в его основе файла. В данной главе мы видели, что fcntl()
используется для следующего:
• Дублирования дескриптора файла, имитирования
dup()
и почти имитирования dup2()
.
• Получения и установки флага close-on-exec. Флаг close-on-exec является в настоящее время единственным атрибутом дескриптора файла, но он важен. Он не копируется в результате действия
dup()
, но должен явным образом устанавливаться для дескрипторов файлов, которые не должны оставаться открытыми после выполнения exec. На практике, это должно быть сделано для большинства дескрипторов файла.
• Получение и установка флагов, управляющих нижележащим файлом. Из них
O_NONBLOCK
является, пожалуй, наиболее полезным, по крайней мере, для FIFO и каналов. Это определенно самый сложный флаг.
Упражнения
1. Напишите программу, которая выводит как можно больше сведений о текущем процессе: PID, PPID, открытые файлы, текущий каталог, значение относительного приоритета и т.д. Как вы можете сказать, какие файлы открыты? Если несколько дескрипторов файлов ссылаются на один и тот же файл, укажите это. (Опять-таки, как вы можете это узнать?)
2. Как вы думаете,
atexit()
хранит указатели на функции обратного вызова? Реализуйте atexit()
, держа в уме принцип GNU «никаких произвольных ограничений». Набросайте схему (псевдокод) для exit()
. Каких сведений (внутренностей библиотеки
) вам не хватает, чтобы написать exit()
?
3. Программа
xargs
предназначена для многократных запусков команды и аргументов, когда аргументов слишком много для непосредственного набора в командной строке. Программа работает, считывая строки из стандартного ввода, рассматривая каждую строку в качестве отдельного аргумента для указанной команды, и упаковывая аргументы до тех пор, пока они остаются в пределах максимально допустимого для системы. Например:
$ grep ARG_MAX /usr/include/*.h /usr/include/*/*.h /* Командная строка */
bash: /bin/grep: Argument list too long /* Сообщение оболочки об ошибке */
$ find /usr/include -name '*.h' | xargs grep ARG_MAX /* find b xargs работают */
/usr/include/sys/param.h:#define NCARGS ARG_MAX
...
Константа
ARG_MAX
в
представляет сочетание общей памяти, используемой средой, и аргументов командной строки. Стандарт POSIX не говорит, включает ли это массивы указателей или просто сами строки.
Напишите простую версию
xargs
, которая работает указанным способом. Не забудьте об окружении при вычислении размера необходимого пространства. Убедитесь, что тщательно управляете памятью.
4. Компоновка значения status, заполняемого функциями
wait()
и waitpid()
, стандартом POSIX не определяется. Хотя и историческое, это 16-разрядное значение, которое выглядит, как показано на рис. 9.8.
Рис. 9.8. Компоновка значения status функции
wait()
• Ненулевое значение в битах 0–7 указывает на завершение по сигналу.
• Все единичные биты в поле сигнала указывает, что порожденный процесс остановлен. В этом случае биты 9-15 содержат номер сигнала.
• Единичное значение бита 8 указывает завершение со снимком процесса.
• Если биты 0–7 равны нулю, процесс завершился нормально. В этом случае биты 9–15 являются статусом завершения.
Напишите с данными сведениями макросы POSIX
WIFEXITED()
и др.
5. Помня, что
dup2()
сначала закрывает запрошенный дескриптор файла, реализуйте dup2()
, используя close()
и fcntl()
. Как вы обработаете случай, когда fcntl()
возвращает значение меньше запрошенного?
6. Есть ли на вашей системе каталог
/dev/fd
? Если есть, как он реализован?
7. Напишите новую версию
ch09-pipeline.c
, которая порождает лишь один процесс. После порождения родитель должен поменять дескрипторы своих файлов и сам выполнить exec для одной из новых программ.
8. (Трудное) Как вы можете узнать, вызывал ли ваш процесс когда-нибудь
chroot()
? Напишите программу, которая проверяет это и выводит сообщение с ответом да или нет. Можно ли обмануть вашу программу? Если да, как?
9. Есть ли на вашей системе каталог
/proc
? Если да, доступ к какой информации о процессе он обеспечивает?
Как мы говорили в главе 1 «Введение», если бы нужно было резюмировать Unix (а следовательно, и Linux) в трёх словах, это были бы «файлы и процессы». Теперь, когда мы увидели, как работать с файлами и каталогами, время взглянуть на оставшуюся часть утверждения: процессы. В частности, мы исследуем, как создаются и управляются процессы, как они взаимодействуют с открытыми файлами и как они могут взаимодействовать друге другом. Последующие главы исследуют сигналы — грубый способ дать возможность одному процессу (или ядру) сообщить другому о том, что произошло некоторое событие — и проверку прав доступа.
В данной главе картина начинает усложняться. В частности, для полноты мы должны упомянуть о вещах, которые не будут рассматриваться до конца главы или до конца книги В таких случаях мы предусмотрели ссылки вперед, но вы должны быть способны без подготовки уловить суть каждого раздела.
9.1. Создание и управление процессами
В отличие от многих предшествующих и последующих операционных систем, создание процессов в Unix задумывалось (и было сделано) дешевым. Более того, Unix разделяет идеи «создания нового процесса» и «запуска данной программы в процессе». Это было элегантное проектное решение, которое упрощает многие операции.
9.1.1. Создание процесса: fork()
Первым шагом в запуске новой программы является вызов
fork()
:
#include /* POSIX */
#include
pid_t fork(void);
Использование
fork()
просто. Перед вызовом один процесс, который мы называем родительским, является запущенным. Когда fork()
возвращается, имеется уже два процесса: родительский и порожденный (child).
Вот ключ: оба процесса выполняют одну и ту же программу. Два процесса могут различить себя, основываясь на возвращённом
fork()
значении:
Отрицательное
Если была ошибка,
fork()
возвращает -1, а новый процесс не создается. Работу продолжает первоначальный процесс.
Нулевое
В порожденном процессе
fork()
возвращает 0.
Положительное
В родительском процессе
fork()
возвращает положительный идентификационный номер (PID) порожденного процесса.
Код шаблона для создания порожденного процесса выглядит следующим образом:
pid_t child;
if ((child = fork()) < 0)
/* обработать ошибку */
else if (child == 0)
/* это новый процесс */
else
/* это первоначальный родительский процесс */
pid_t
является знаковым целым типом для хранения значений PID. Скорее всего, это просто int
, но специальный тип делает код более понятным, поэтому он должен использоваться вместо int
.
На языке Unix, помимо названия системного вызова, слово «fork» является и глаголом, и существительным[88]. Мы можем сказать, что «один процесс ответвляет другой», и что «после разветвления работают два процесса». (Думайте «развилка (fork) на дороге», а не «вилка (fork), нож и ложка».)
9.1.1.1. После fork()
: общие и различные атрибуты
Порожденный процесс «наследует» идентичные копии большого числа атрибутов от родителя. Многие из этих атрибутов специализированы и здесь неуместны. Поэтому следующий список намеренно неполон. Существенны следующие:
• Окружение, см. раздел 2.4 «Окружение».
• Все открытые файлы и открытые каталоги; см. раздел 4.4.1 «Понятие о дескрипторах файлов» и раздел 5.3.1 «Базовое чтение каталогов».
• Установки umask; см. раздел 4.6 «Создание файлов».
• Текущий рабочий каталог; см раздел 8.4.1 «Смена каталога:
chdir()
и fchdir()
.
• Корневой каталог; см. раздел 8.6 «Изменение корневого каталога:
chroot()
».
• Текущий приоритет (иначе называемый «значение nice»; вскоре мы это обсудим; см раздел 9.1.3 «Установка приоритета процесса:
nice()
»).
• Управляющие терминалы. Это устройство терминала (физическая консоль или окно эмулятора терминала), которому разрешено посылать процессу сигналы (такие, как CTRL-Z для прекращения выполняющихся работ). Это обсуждается далее в разделе 9.2.1 «Обзор управления работой».
• Маска сигналов процесса и расположение всех текущих сигналов (еще не обсуждалось; см. главу 10 «Сигналы»).
• Реальный, эффективный и сохраненный ID пользователя, группы и набора дополнительных групп (еще не обсуждалось; см. главу 11 «Права доступа и ID пользователя и группы»).
Помимо возвращаемого значения
fork()
два процесса различаются следующим образом:
• У каждого есть уникальный ID процесса и ID родительского процесса (PID и PPID) Они описаны в разделе 9.1.2 «Идентификация процесса:
getpid()
и getppid()
».
• PID порожденного процесса не будет равняться ID любой существующей группы процессов (см. раздел 9.2 «Группы процессов»).
• Аккумулированное время использования процессора для порожденного процесса и его будущих потомков инициализируется нулем. (Это имеет смысл; в конце концов, это совершенно новый процесс.)
• Любые сигналы, которые были ожидающими в родительском процессе, в порожденном сбрасываются, также как ожидающие аварийные сигналы и таймеры. (Мы еще не рассматривали эти темы; см. главу 10 «Сигналы» и раздел 14.3.3 «Интервальные таймеры:
setitimer()
и getitimer()
».)
• Блокировки файлов в родительском процессе не дублируются в порожденном (также еще не обсуждалось; см. раздел 14.2 «Блокировка файлов»).
9.1.1.2. Разделение дескрипторов файлов
Атрибуты, которые порожденный процесс наследует от родителя, устанавливаются в те же значения, которые были в родительском процессе в момент выполнения
fork()
. Однако, с этого момента два процесса продолжают идти собственными путями (большей частью) независимо один от другого. Например, если порожденный процесс изменяет каталог, каталог родительского процесса не затрагивается. Сходным образом, если порожденный изменяет среду, среда родителя не меняется.
Открытые файлы являются важным исключением из этого правила. Дескрипторы открытых файлов являются разделяемыми, и действия одного процесса с разделяемым дескриптором файла затрагивает состояние файла также и для другого процесса. Это лучше всего понять, изучив рис. 9.1.
Рис. 9.1. Разделение дескрипторов файлов
Рисунок отображает внутренние структуры данных ядра. Ключевой структурой данных является таблица файлов. Каждый элемент ссылается на открытый файл. Помимо других учетных данных, таблица файлов содержит текущее положение (смещение чтения/записи) в файле. Оно устанавливается либо автоматически каждый раз при чтении или записи файла, либо непосредственно через
lseek()
(см. раздел 4.5 «Произвольный доступ: перемещения внутри файла»).
Дескриптор файла, возвращенный функциями
open()
или creat()
, действует как индекс имеющегося в каждом процессе массива указателей на таблицу файлов. Размер этого массива не превышает значение, возвращенное getdtablesize()
(см. раздел 4.4.1 «Понятие о дескрипторах файлов»).
На рис. 9.1 показаны два процесса, разделяющие стандартный ввод и стандартный вывод; для каждого из процессов указаны одни и те же элементы в таблице файлов. Поэтому, когда процесс 45 (порожденный) осуществляет
read()
, общее смещение обновляется; следующий раз, когда процесс 42 (родитель) осуществляет read()
, он начинает с позиции, в которой закончила чтение read()
процесса 45.
Это легко можно видеть на уровне оболочки:
$ cat data /* Показать содержание демонстрационного файла */
line 1
line 2
line 3
line 4
$ ls -l test1 ; cat test1 /* Режим и содержание тестовой программы */
-rwxr-xr-x 1 arnold devel 93 Oct 20 22:11 test1
#! /bin/sh
read line ; echo p: $line /* Прочесть строку в родительской оболочке,
вывести ее */
( read line ; echo с: $line ) /* Прочесть строку в порожденной оболочке,
вывести ее */
read line ; echo p: $line /* Прочесть строку в родительской оболочке,
вывести ее */
$ test1 < data /* Запустить программу */
p: line 1 /* Родитель начинает сначала */
c: line 2 /* Порожденный продолжает оттуда, где остановился родитель */
p: line 3 /* Родитель продолжает оттуда, где остановился порожденный */
Первая исполняемая строка
test1
читает из стандартного ввода строку, изменяя смещение файла. Следующая строка test1
запускает команды, заключенные между скобками, в подоболочке (subshell). Это отдельный процесс оболочки, созданный — как вы догадались — с помощью fork()
. Порожденная подоболочка наследует от родителя стандартный ввод, включая текущее смещение. Этот процесс читает строку и обновляет разделяемое смещение в файле. Когда третья строка, снова в родительской оболочке, читает файл, она начинает там, где остановился порожденный.
Хотя команда
read
встроена в оболочку, все работает таким же образом и для внешних команд. В некоторых ранних Unix-системах была команда line
, которая читала одну строку ввода (по одному символу за раз!) для использования в сценариях оболочки; если бы смещение файла не было разделяемым, было бы невозможно использовать такую команду в цикле.
Разделение дескрипторов файлов и наследование играют центральную роль в перенаправлении ввода/вывода оболочки; системные вызовы и их семантика делают примитивы уровня оболочки простыми для реализации на С, как мы позже увидим в данной главе.
9.1.1.3. Разделение дескрипторов файлов и close()
Тот факт, что несколько дескрипторов файлов могут указывать на один и тот же открытый файл, имеет важное следствие: файл не закрывается до тех пор, пока не будут закрыты все дескрипторы файла.
Позже в главе мы увидим, что несколько дескрипторов для одного файла могут существовать не только для разных процессов, но даже и внутри одного и того же процесса; это правило особенно важно для работы с каналами (pipes).
Если вам нужно узнать, открыты ли два дескриптора для одного и того же файла, можете использовать
fstat()
(см. раздел 5.4.2 «Получение сведений о файле») для двух дескрипторов с двумя различными структурами struct stat
. Если соответствующие поля st_dev
и st_ino
равны, это один и тот же файл.
Позже в главе мы завершим обсуждение манипуляций с дескрипторами файлов и таблицей дескрипторов файлов.
fork()Первым шагом в запуске новой программы является вызов
fork()#include /* POSIX */ #include pid_t fork(void);Использование
fork()fork()Вот ключ: оба процесса выполняют одну и ту же программу. Два процесса могут различить себя, основываясь на возвращённом
fork()Отрицательное
Если была ошибка,
fork()Нулевое
В порожденном процессе
fork()Положительное
В родительском процессе
fork()Код шаблона для создания порожденного процесса выглядит следующим образом:
pid_t child;if ((child = fork()) < 0) /* обработать ошибку */else if (child == 0) /* это новый процесс */else /* это первоначальный родительский процесс */pid_tintintНа языке Unix, помимо названия системного вызова, слово «fork» является и глаголом, и существительным[88]. Мы можем сказать, что «один процесс ответвляет другой», и что «после разветвления работают два процесса». (Думайте «развилка (fork) на дороге», а не «вилка (fork), нож и ложка».)
9.1.1.1. После fork()
: общие и различные атрибуты
fork()Порожденный процесс «наследует» идентичные копии большого числа атрибутов от родителя. Многие из этих атрибутов специализированы и здесь неуместны. Поэтому следующий список намеренно неполон. Существенны следующие:
• Окружение, см. раздел 2.4 «Окружение».
• Все открытые файлы и открытые каталоги; см. раздел 4.4.1 «Понятие о дескрипторах файлов» и раздел 5.3.1 «Базовое чтение каталогов».
• Установки umask; см. раздел 4.6 «Создание файлов».
• Текущий рабочий каталог; см раздел 8.4.1 «Смена каталога:
chdir()fchdir()• Корневой каталог; см. раздел 8.6 «Изменение корневого каталога:
chroot()• Текущий приоритет (иначе называемый «значение nice»; вскоре мы это обсудим; см раздел 9.1.3 «Установка приоритета процесса:
nice()• Управляющие терминалы. Это устройство терминала (физическая консоль или окно эмулятора терминала), которому разрешено посылать процессу сигналы (такие, как CTRL-Z для прекращения выполняющихся работ). Это обсуждается далее в разделе 9.2.1 «Обзор управления работой».
• Маска сигналов процесса и расположение всех текущих сигналов (еще не обсуждалось; см. главу 10 «Сигналы»).
• Реальный, эффективный и сохраненный ID пользователя, группы и набора дополнительных групп (еще не обсуждалось; см. главу 11 «Права доступа и ID пользователя и группы»).
Помимо возвращаемого значения
fork()• У каждого есть уникальный ID процесса и ID родительского процесса (PID и PPID) Они описаны в разделе 9.1.2 «Идентификация процесса:
getpid()getppid()• PID порожденного процесса не будет равняться ID любой существующей группы процессов (см. раздел 9.2 «Группы процессов»).
• Аккумулированное время использования процессора для порожденного процесса и его будущих потомков инициализируется нулем. (Это имеет смысл; в конце концов, это совершенно новый процесс.)
• Любые сигналы, которые были ожидающими в родительском процессе, в порожденном сбрасываются, также как ожидающие аварийные сигналы и таймеры. (Мы еще не рассматривали эти темы; см. главу 10 «Сигналы» и раздел 14.3.3 «Интервальные таймеры:
setitimer()getitimer()• Блокировки файлов в родительском процессе не дублируются в порожденном (также еще не обсуждалось; см. раздел 14.2 «Блокировка файлов»).
9.1.1.2. Разделение дескрипторов файлов
Атрибуты, которые порожденный процесс наследует от родителя, устанавливаются в те же значения, которые были в родительском процессе в момент выполнения
fork()Открытые файлы являются важным исключением из этого правила. Дескрипторы открытых файлов являются разделяемыми, и действия одного процесса с разделяемым дескриптором файла затрагивает состояние файла также и для другого процесса. Это лучше всего понять, изучив рис. 9.1.
Рис. 9.1. Разделение дескрипторов файлов
Рисунок отображает внутренние структуры данных ядра. Ключевой структурой данных является таблица файлов. Каждый элемент ссылается на открытый файл. Помимо других учетных данных, таблица файлов содержит текущее положение (смещение чтения/записи) в файле. Оно устанавливается либо автоматически каждый раз при чтении или записи файла, либо непосредственно через
lseek()Дескриптор файла, возвращенный функциями
open()creat()getdtablesize()На рис. 9.1 показаны два процесса, разделяющие стандартный ввод и стандартный вывод; для каждого из процессов указаны одни и те же элементы в таблице файлов. Поэтому, когда процесс 45 (порожденный) осуществляет
read()read()read()Это легко можно видеть на уровне оболочки:
$ cat data /* Показать содержание демонстрационного файла */line 1line 2line 3line 4$ ls -l test1 ; cat test1 /* Режим и содержание тестовой программы */-rwxr-xr-x 1 arnold devel 93 Oct 20 22:11 test1#! /bin/shread line ; echo p: $line /* Прочесть строку в родительской оболочке, вывести ее */( read line ; echo с: $line ) /* Прочесть строку в порожденной оболочке, вывести ее */read line ; echo p: $line /* Прочесть строку в родительской оболочке, вывести ее */$ test1 < data /* Запустить программу */p: line 1 /* Родитель начинает сначала */c: line 2 /* Порожденный продолжает оттуда, где остановился родитель */p: line 3 /* Родитель продолжает оттуда, где остановился порожденный */Первая исполняемая строка
test1test1fork()Хотя команда
readlineРазделение дескрипторов файлов и наследование играют центральную роль в перенаправлении ввода/вывода оболочки; системные вызовы и их семантика делают примитивы уровня оболочки простыми для реализации на С, как мы позже увидим в данной главе.
9.1.1.3. Разделение дескрипторов файлов и close()
close()Тот факт, что несколько дескрипторов файлов могут указывать на один и тот же открытый файл, имеет важное следствие: файл не закрывается до тех пор, пока не будут закрыты все дескрипторы файла.
Позже в главе мы увидим, что несколько дескрипторов для одного файла могут существовать не только для разных процессов, но даже и внутри одного и того же процесса; это правило особенно важно для работы с каналами (pipes).
Если вам нужно узнать, открыты ли два дескриптора для одного и того же файла, можете использовать
fstat()struct statst_devst_inoПозже в главе мы завершим обсуждение манипуляций с дескрипторами файлов и таблицей дескрипторов файлов.
9.1.2. Идентификация процесса: getpid()
и getppid()
getpid()getppid()У каждого процесса есть уникальный ID номер процесса (PID). Два системных вызова предоставляют текущий PID и PID родительского процесса:
#include /* POSIX */ #include pid_t getpid(void);pid_t getppid(void);Функции так просты, как выглядят:
pid_t getpid(void) pid_t getppid(void)Значения PID уникальны; по определению, не может быть двух запущенных процессов с одним и тем же PID. PID обычно возрастают в значении, так что порожденный процесс имеет обычно больший PID, чем его родитель. Однако, на многих системах значения PID переполняются; когда достигается значение системного максимума для PID, следующий процесс создается с наименьшим не используемым номером PID. (Ничто в POSIX не требует такого поведения, и некоторые системы назначают неиспользуемые номера PID случайным образом.)
Если родительский процесс завершается, порожденный получает нового родителя,
initinitch09-reparent.сfork()1 /* ch09-reparent.c --- показывает, что getppid() может менять значения */23 #include 4 #include 5 #include 6 #include 78 /* main --- осуществляет работу */910 int main(int argc, char **argv)11 {12 pid_t pid, old_ppid, new_ppid;13 pid_t child, parent;1415 parent = getpid(); /* перед fork() */1617 if ((child = fork()) < 0) {18 fprintf(stderr, "%s: fork of child failed: %s\n",19 argv[0], strerror(errno));20 exit(1);21 } else if (child == 0) {22 old_ppid = getppid();23 sleep(2); /* см. главу 10 */24 new_ppid = getppid();25 } else {26 sleep(1);27 exit(0); /* родитель завершается после fork() */28 }2930 /* это выполняет только порожденный процесс */31 printf("Original parent: %d\n", parent);32 printf("Child: %d\n", getpid());33 printf("Child's old ppid: %d\n", old_ppid);34 printf("Child's new ppid: %d\n", new_ppid);3536 exit(0);37 }Строка 15 получает PID начального процесса, используя
getpid()Строки 21–24 выполняются порожденным процессом: строка 22 получает PPID. Строка 23 приостанавливает процесс на две секунды (сведения о
sleep()sleep()alarm()SIGALRMСтроки 25–27 исполняются в родительском процессе. Строка 26 задерживает родителя на одну секунду, давая порожденному процессу достаточно времени для осуществления первого вызова
getppid()Строки 31–34 выводят значения. Обратите внимание, что переменная
parent$ ch09-reparent /* Запуск программы */$ Original parent: 6582 /* Программа завершается: приглашение оболочки и вывод порожденного процесса */Child: 6583Child's old ppid: 6582Child's new ppid: 1Помните, что обе программы выполняются параллельно. Графически это изображено на рис. 9.2.
Рис. 9.2. Два параллельно исполняющихся процесса после разветвления
ЗАМЕЧАНИЕ. Использование
sleep()wait()waitpid()wait()waitpid()
9.1.3. Установка приоритетов процесса: nice()
Когда процессы запущены, ядро динамически меняет приоритет каждого процесса. Как и в жизни, элементы с большим приоритетом получают внимание до элементов с меньшим приоритетом. Короче говоря, каждому процессу выделяется небольшая порция времени для исполнения, которая называется квантом времени (time slice). Когда квант истекает, если текущий процесс все еще является процессом с наивысшим приоритетом, ему разрешается продолжать.
Linux, как и Unix, обеспечивает вытесняющую многозадачность. Это означает, что ядро может вытеснить процесс (приостановить его), если настало время дать возможность поработать другому процессу. Приоритет длительное время работающих процессов (например, процессов, выполняющих интенсивные вычисления), снижается в конце их кванта времени, поэтому они дают шанс другим процессам получить время процессора. Сходным образом, процессам, длительное время бездействовавшим в ожидании завершения ввода/вывода (таким, как интерактивный текстовый редактор), приоритет повышается, так что они могут ответить на ввод/вывод, когда он происходит. Короче, ядро гарантирует, что все процессы, усредненные по времени, получают свою «справедливую долю» времени процессора. Повышение и понижение приоритетов является частью этого процесса.
Проектирование хорошего планировщика процессов для ядра является искусством; практические подробности выходят за рамки данной книги. Однако, процесс может влиять на назначения приоритетов ядром посредством своего значения относительного приоритета (nice).
Значение относительного приоритета является указанием того, насколько «приятным» хочет быть процесс в отношении других процессов. В соответствии с этим большие значения означают во все большей степени терпеливые процессы; т.е. те, которые все более приятны другим, снижая свой приоритет по отношению к ним.
Отрицательное значение относительного приоритета, с другой стороны, означает, что процесс желает быть «менее приятным» по отношению к другим. Такой процесс более эгоистичный, требуя себе большего количества времени процессора[89]. К счастью, в то время как пользователи могут повышать значение относительного приоритета (быть более приятными), лишь
root
может снижать значение относительного приоритета (быть менее приятным).
Значение относительного приоритета является лишь одним фактором в уравнении, используемом ядром для вычисления приоритета; это не значение самого приоритета, которое изменяется с течением времени на основе поведения процесса и состояния других процессов системы. Для изменения значения относительного приоритета используется системный вызов
nice()
:
#include /* XSI */
int nice(int inc);
Значение относительного приоритета по умолчанию равно 0. Разрешен диапазон значений от -20 до 19. Это требует некоторой привычки. Чем более отрицательное значение, тем выше приоритет процесса: -20 является наивысшим приоритетом (наименьшая приятность), а 19 — наинизшим приоритетом (наибольшая приятность)
Аргумент
inc
является приращением, на который надо изменить значение приоритета. Для получения текущего значения, не изменяя его, используйте 'nice(0)
'. Если результат 'текущий_относительный_приоритет + inc
' выйдет за пределы от -20 до 19, система принудительно включит его в этот диапазон.
Возвращаемое значение является новым значением относительного приоритета или -1, если возникла ошибка. Поскольку -1 также является действительным значением относительного приоритета, при вызове
nice()
следует сначала явным образом установить errno
в ноль, а затем проверить его насчет имевшихся проблем:
int niceval;
int inc = /* любое значение */;
errno = 0;
if ((niceval = nice(inc)) < 0 && errno != 0) {
fprintf(stderr, "nice(%d) failed: %s\n", inc, strerror(errno));
/* другое восстановление */
}
Этот пример может завершиться неудачей, если в
inc
отрицательное значение, а процесс не запущен как root
.
9.1.3.1. POSIX против действительности
Диапазон значений относительного приоритета от -20 до 19, которые использует Linux, имеет исторические корни; он ведет начало по крайней мерее V7. POSIX выражает состояние менее прямым языком, что дает возможность большей гибкости, сохраняя в то же время историческую совместимость. Это также затрудняет чтение и понимание стандарта, вот почему вы и читаете эту книгу. Итак, вот как описывает это POSIX
Во-первых, значение относительного приоритета процесса, поддерживаемое системой, колеблется от 0 до '
(2 * NZERO) - 1
'. Константа NZERO
определена в
и должна равняться по крайней мере 20. Это дает диапазон 0–39.
Во-вторых, как мы описывали, сумма текущего значения относительного приоритета и приращение
incr
загоняются в этот диапазон.
В заключение, возвращаемое
nice()
значение является значением относительного приоритета процесса минус NZERO
. При значении NZERO
20 это дает первоначальный диапазон от -20 до 19, который мы описали вначале.
Результатом является то, что возвращаемое nice() значение в действительности изменяется от '
-NZERO
' до 'NZERO-1
', и лучше всего писать свой код в терминах этой именованной константы. Однако, на практике трудно найти систему, в которой NZERO
не было бы равно 20.
nice()Когда процессы запущены, ядро динамически меняет приоритет каждого процесса. Как и в жизни, элементы с большим приоритетом получают внимание до элементов с меньшим приоритетом. Короче говоря, каждому процессу выделяется небольшая порция времени для исполнения, которая называется квантом времени (time slice). Когда квант истекает, если текущий процесс все еще является процессом с наивысшим приоритетом, ему разрешается продолжать.
Linux, как и Unix, обеспечивает вытесняющую многозадачность. Это означает, что ядро может вытеснить процесс (приостановить его), если настало время дать возможность поработать другому процессу. Приоритет длительное время работающих процессов (например, процессов, выполняющих интенсивные вычисления), снижается в конце их кванта времени, поэтому они дают шанс другим процессам получить время процессора. Сходным образом, процессам, длительное время бездействовавшим в ожидании завершения ввода/вывода (таким, как интерактивный текстовый редактор), приоритет повышается, так что они могут ответить на ввод/вывод, когда он происходит. Короче, ядро гарантирует, что все процессы, усредненные по времени, получают свою «справедливую долю» времени процессора. Повышение и понижение приоритетов является частью этого процесса.
Проектирование хорошего планировщика процессов для ядра является искусством; практические подробности выходят за рамки данной книги. Однако, процесс может влиять на назначения приоритетов ядром посредством своего значения относительного приоритета (nice).
Значение относительного приоритета является указанием того, насколько «приятным» хочет быть процесс в отношении других процессов. В соответствии с этим большие значения означают во все большей степени терпеливые процессы; т.е. те, которые все более приятны другим, снижая свой приоритет по отношению к ним.
Отрицательное значение относительного приоритета, с другой стороны, означает, что процесс желает быть «менее приятным» по отношению к другим. Такой процесс более эгоистичный, требуя себе большего количества времени процессора[89]. К счастью, в то время как пользователи могут повышать значение относительного приоритета (быть более приятными), лишь
rootЗначение относительного приоритета является лишь одним фактором в уравнении, используемом ядром для вычисления приоритета; это не значение самого приоритета, которое изменяется с течением времени на основе поведения процесса и состояния других процессов системы. Для изменения значения относительного приоритета используется системный вызов
nice()#include /* XSI */ int nice(int inc);Значение относительного приоритета по умолчанию равно 0. Разрешен диапазон значений от -20 до 19. Это требует некоторой привычки. Чем более отрицательное значение, тем выше приоритет процесса: -20 является наивысшим приоритетом (наименьшая приятность), а 19 — наинизшим приоритетом (наибольшая приятность)
Аргумент
incnice(0)текущий_относительный_приоритет + incВозвращаемое значение является новым значением относительного приоритета или -1, если возникла ошибка. Поскольку -1 также является действительным значением относительного приоритета, при вызове
nice()errnoint niceval;int inc = /* любое значение */;errno = 0;if ((niceval = nice(inc)) < 0 && errno != 0) { fprintf(stderr, "nice(%d) failed: %s\n", inc, strerror(errno)); /* другое восстановление */}Этот пример может завершиться неудачей, если в
incroot9.1.3.1. POSIX против действительности
Диапазон значений относительного приоритета от -20 до 19, которые использует Linux, имеет исторические корни; он ведет начало по крайней мерее V7. POSIX выражает состояние менее прямым языком, что дает возможность большей гибкости, сохраняя в то же время историческую совместимость. Это также затрудняет чтение и понимание стандарта, вот почему вы и читаете эту книгу. Итак, вот как описывает это POSIX
Во-первых, значение относительного приоритета процесса, поддерживаемое системой, колеблется от 0 до '
(2 * NZERO) - 1NZEROВо-вторых, как мы описывали, сумма текущего значения относительного приоритета и приращение
incrВ заключение, возвращаемое
nice()NZERONZEROРезультатом является то, что возвращаемое nice() значение в действительности изменяется от '
-NZERONZERO-1NZERO
9.1.4. Запуск новой программы: семейство exec()
После запуска нового процесса (посредством
fork()
) следующим шагом является запуск в процессе другой программы. Имеется несколько функций, которые служат различным целям:
#include /* POSIX */
int execve(const char *filename, /* Системный вызов */
char *const argv[], char *const envp[]);
int execl(const char *path, const char *arg, ...); /* Оболочки */
int execlp(const char *file, const char *arg, ...);
int execle(const char *path, const char *arg, ..., char *const envp[]);
int execv(const char *path, char *const argv[]);
int execvp(const char *file, char *const argv[]);
Мы ссылаемся на эти функции как на «семейство
exec()
». Функции с именем exec()
нет; вместо этого мы используем это имя для обозначения любой из перечисленных выше функций. Как и в случае с fork()
, «exec
» используется на языке Unix и в качестве глагола, означающего исполнение (запуск) программы, и в качестве существительного.
9.1.4.1. Системный вызов execve()
Простейшей для объяснения функцией является
execve()
. Она является также лежащим в основе системным вызовом. Другие являются функциями-оболочками, как вскоре будет объяснено.
int execve(const char *filename, char *const argv[],
char* const envp[]);
filename
является именем программы для исполнения. Это может быть именем полного или относительного пути. Файл должен иметь формат исполняемого файла, который понимает ядро. Современные системы используют формат исполняемого файла ELF (Extensible Linking Format — открытый формат компоновки). GNU/Linux распознает ELF и несколько других форматов. С помощью execve()
можно исполнять интерпретируемые сценарии, если они используют особую первую строку с именем интерпретатора, начинающуюся с '#!
'. (Сценарии, которые не начинаются с '#!
', потерпят неудачу.) В разделе 1.1.3 «Исполняемые файлы» представлен пример использования '#!'. argv является стандартным списком аргументов С — массив символьных указателей на строки аргументов, включая значение для использования с argv[0]
[90], завершающийся указателем NULL
.
envp
является окружением для использования новым процессом, с таким же форматом, как глобальная переменная environ
(см. раздел 2.4 «Переменные окружения»). В новой программе это окружение становится начальным значением environ
.
Программа не должна возвращаться из вызова
exec()
. Если она возвращается, возникла проблема. Чаще всего либо не существует затребованная программа, либо она существует, но не является исполняемой (значения для errno ENOENT
и EACCESS
соответственно). Может быть множество других ошибок; см. справочную страницу execve(2).
В предположении, что вызов был успешным, текущее содержимое адресного пространства процесса сбрасывается. (Ядро сначала сохраняет в безопасном месте данные
argv
и envp
.) Ядро загружает для новой программы исполняемый код вместе со всеми глобальными и статическими переменными. Затем ядро инициализирует переменные окружения переданными execve()
данными, а далее вызывает процедуру main()
новой программы с переданным функции execve()
массивом argv
. Подсчитывается число аргументов и это значение передается main()
в argc
.
К этому моменту новая программа запущена. Она не знает (и не может определить), какая программа была в процессе до нее. Обратите внимание, что ID процесса не меняется. Многие другие атрибуты при вызове
exec
сохраняются; вскоре мы рассмотрим это более подробно.
exec()
для процесса можно сравнить с ролями, которые играют в жизни люди. В различное время в течение дня один человек может быть родителем, супругом, другом, студентом или рабочим, покупателем в магазине и т.д. Это одна и та же личность, исполняющая различные роли. Также и процесс — его PID, открытые файлы, текущий каталог и т.п. — не изменяются, тогда как выполняемая работа - запущенная с помощью exec()
программа — может измениться.
9.1.4.2. Функции-оболочки: execl()
и др.
Пять дополнительных функций, действующих в качестве оболочек, предоставляют более удобные интерфейсы для
execve()
. В первой группе все принимают список аргументов, каждый из которых передается в виде явного параметра функции:
int execl(const char *path, const char *arg, ...)
Первый аргумент,
path
, является путем к исполняемому файлу. Последующие аргументы, начиная с arg
, являются отдельными элементами, которые должны быть помещены в argv
. Как и ранее, явным образом должен быть включен argv[0]
. Вы должны в качестве последнего аргумента передать завершающий указатель NULL
, чтобы execl()
смогла определить, где заканчивается список аргументов. Новая программа наследует любые переменные окружения, которые находятся в переменной environ
.
int execlp(const char *file, const char *arg, ...)
Эта функция подобна
execl()
, но она имитирует механизм поиска команд оболочки, разыскивая file
в каждом каталоге, указанном в переменной окружения PATH
. Если file
содержит символ /
, этот поиск не осуществляется. Если PATH
в окружении не присутствует, execlp()
использует путь по умолчанию. В GNU/Linux по умолчанию используется ":/bin:/usr/bin
", но в других системах может быть другое значение. (Обратите внимание, что ведущее двоеточие в PATH
означает, что сначала поиск осуществляется в текущем каталоге.)
Более того, если файл найден и имеет право доступа на исполнение, но не может быть исполнен из-за того, что неизвестен его формат,
execlp()
считает, что это сценарий оболочки и запускает оболочку с именем файла в качестве аргумента.
int execle(const char *path, const char *arg, ...,
char *const envp[])
Эта функция также подобна
execl()
, но принимает дополнительный аргумент, envp
, который становится окружением новой программы. Как и в случае с execl()
, вы должны для завершения списка аргументов поместить перед envp
указатель NULL
.
Вторая группа функций-оболочек принимает массив в стиле
argv
:
int execv(const char *path, char *const argv[])
Эта функция подобна
execve()
, но новая программа наследует любое окружение, которое находится в переменной environ текущей программы.
int execvp(const char *file, char *const argv[])
Эта функция подобна
execv()
, но она осуществляет такой же поиск в PATH
, как и функция execlp()
. Она также переходит на исполнение сценария оболочки, если найденный файл не может быть исполнен непосредственно.
В табл. 9.1 подведены итоги для шести функций
exec()
.
Таблица 9.1. Сводка семейства функций
exec()
по алфавиту
Функция
Поиск пути
Окружение пользователя
Назначение
execl()
√
Исполняет список аргументов.
execle()
Исполняет список аргументов с окружением.
execlp()
√
√
Исполняет список аргументов с поиском пути
execv()
√
Исполняет с argv
execve()
Исполняет с argv
и окружением (системный вызов).
execvp()
√
√
Исполняет с argv
и с поиском пути
Функций
execlp()
и execvp()
лучше избегать, если вы не знаете, что переменная окружения PATH
содержит приемлемый список каталогов.
9.1.4.3. Имена программ и argv[0]
До сих пор мы все время считали
argv[0]
именем программы. Мы знаем, что оно может содержать, а может и не содержать символ /
, в зависимости от способа вызова программы, если этот символ содержится, это хорошая подсказка к тому, что для вызова программы использовалось имя пути.
Однако, как должно быть ясно к этому времени, то, что
argv[0]
содержит имя файла, является лишь соглашением. Ничто не может воспрепятствовать передаче вами вызываемой программе в качестве argv[0]
произвольной строки. Следующая программа, ch09-run.c
, демонстрирует передачу произвольной строки:
1 /* ch09-run.c --- запуск программы с другим именем и любыми аргументами */
2
3 #include
4 #include
5 #include
6
7 /* main --- настроить argv и запустить указанную программу */
8
9 int main(int argc, char **argv)
10 {
11 char *path;
12
13 if (argc < 3) {
14 fprintf(stderr, "usage: %s path arg0 [ arg ... ]\n", argv[0]);
15 exit(1);
16 }
17
18 path = argv[1];
19
20 execv(path, argv + 2); /* skip argv[0] and argv[1] */
21
22 fprintf(stderr, "%s: execv() failed: %s\n", argv[0],
23 strerror(errno));
24 exit(1);
25 }
Первый аргумент является путем к запускаемой программе, а второй аргумент является новым именем для программы (которое большинство утилит игнорируют, кроме сообщений об ошибках); все остальные аргументы передаются вызываемой программе.
Строки 13–16 осуществляют проверку ошибок. Строка 18 сохраняет путь в
path
Строка 20 осуществляет exec
; если программа доходит до строк 22–23, это указывает на ошибку. Вот что происходит при запуске программы:
$ ch09-run /bin/grep whoami foo /* Запустить grep */
a line /* Входная строка не подходит */
a line with foo in it /* Входная строка подходит */
a line with foo in it /* Это выводится */
^D /* EOF */
$ ch09-run nonexistent-program foo bar /* Демонстрация неудачи */
ch09-run: execv() failed: No such file or directory
Следующий пример несколько неестественен: мы заставили
ch09-run
запустить себя, передав в качестве имени программы 'foo
'. Поскольку аргументов для второго запуска недостаточно, она выводит сообщение об использовании и завершается:
$ ch09-run ./ch09-run foo
usage: foo path arg() [ arg ... ]
Хотя она и не очень полезна,
ch09-run
ясно показывает, что argv[0]
не обязательно должен иметь какое-нибудь отношение к файлу, который в действительности запускается.
В System III (примерно в 1980-м) команды
cp
, ln
и mv
представляли один исполняемый файл с тремя ссылками с этими именами в /bin
. Программа проверяла argv[0]
и решала, что она должна делать. Это сохраняло некоторое количество дискового пространства за счет усложнения исходного кода и форсирования выполнения программой действия по умолчанию при запуске с неизвестным именем. (Некоторые современные коммерческие системы Unix продолжают эту практику!) Без явной формулировки причин GNU Coding Standards рекомендует, чтобы программы не основывали свое поведение на своем имени. Одна причина, которую мы видели, состоит в том, что администраторы часто устанавливают GNU версию утилиты наряду со стандартной версией коммерческих систем Unix, используя префикс g: gmake
, gawk
и т.д. Если такие программы ожидают лишь стандартные имена, они при запуске с другим именем потерпят неудачу.
Сегодня также дисковое пространство дешево; если из одного и того же исходного кода можно построить две почти идентичные программы, лучше это сделать, использовав
#ifdef
, что у вас есть. Например, grep
и egrep
имеют значительную часть общего кода, но GNU версия строит два отдельных исполняемых файла.
9.1.4.4. Атрибуты, наследуемые exec()
Как и в случае с
fork()
, после вызова программой exec
сохраняется ряд атрибутов:
• Все открытые файлы и открытые каталоги; см. раздел 4.4.1 «Понятие о дескрипторах файлов» и раздел 3.3.1 «Базовое чтение каталогов». (Сюда не входят файлы, помеченные для закрытия при исполнении (close-on-exec), как описано далее в этой главе; см. раздел 9.4.3.1 «Флаг close-on-exec».)
• Установки umask; см. раздел 4.6 «Создание файлов».
• Текущий рабочий каталог, см. раздел 8.4.1 «Изменение каталога:
chdir()
и fchdir()
»
• Корневой каталог; см. раздел 8.6 «Изменение корневого каталога:
chroot()
».
• Текущее значение относительного приоритета.
• ID процесса и ID родительского процесса.
• ID группы процесса и контролирующий терминал; см. раздел 9.2.1 «Обзор управления работами».
• Маску сигналов процесса и любые ожидающие сигналы, а также любые не истекшие аварийные сигналы или таймеры (здесь не обсуждается; см. главу 10 «Сигналы»).
• Действительные ID пользователя и ID группы, а также дополнительный набор групп. Эффективные ID пользователя и группы (а следовательно, и сохраненные ID set-user и set-group) могут быть установлены с помощью битов setuid и setgid исполняемого файла. (Ничто из этого пока не обсуждалось; см. главу 11 «Права доступа и ID пользователя и группы».)
• Блокировки файлов сохраняются (также пока не обсуждалось; см. раздел 14.2 «Блокировка файлов»).
• Суммарное использованное время процессора для процесса и его потомков не меняется.
После
exec
размещение сигналов изменяется; дополнительные сведения см. в разделе 10.9 «Сигналы для fork()
и exec()
».
После
exec
все открытые файлы и каталоги остаются открытыми и доступными для использования. Вот как программы наследуют стандартные ввод, вывод и ошибку: они на месте, когда программа запускается.
В большинстве случаев при исполнении
fork
и exec
для отдельной программы не нужно ничего наследовать, кроме дескрипторов файлов 0, 1 и 2. В этом случае можно вручную закрыть все другие открытые файлы в порожденном процессе после выполнения fork
и до выполнения exec
. В качестве альтернативы можно пометить дескриптор файла для автоматического закрытия системой при исполнении exec; эта последняя возможность обсуждается далее в главе (см раздел 9.4.3.1 «Флаг close-on-exec».)
exec()После запуска нового процесса (посредством
fork()#include /* POSIX */ int execve(const char *filename, /* Системный вызов */char *const argv[], char *const envp[]);int execl(const char *path, const char *arg, ...); /* Оболочки */int execlp(const char *file, const char *arg, ...);int execle(const char *path, const char *arg, ..., char *const envp[]);int execv(const char *path, char *const argv[]);int execvp(const char *file, char *const argv[]);Мы ссылаемся на эти функции как на «семейство
exec()exec()fork()exec
9.1.4.1. Системный вызов execve()
execve()Простейшей для объяснения функцией является
execve()int execve(const char *filename, char *const argv[], char* const envp[]);filenameexecve()#!#!argv[0]NULLenvpenvironenvironПрограмма не должна возвращаться из вызова
exec()errno ENOENTEACCESSВ предположении, что вызов был успешным, текущее содержимое адресного пространства процесса сбрасывается. (Ядро сначала сохраняет в безопасном месте данные
argvenvpexecve()main()execve()argvmain()argcК этому моменту новая программа запущена. Она не знает (и не может определить), какая программа была в процессе до нее. Обратите внимание, что ID процесса не меняется. Многие другие атрибуты при вызове
execexec()exec()
9.1.4.2. Функции-оболочки: execl()
и др.
execl()Пять дополнительных функций, действующих в качестве оболочек, предоставляют более удобные интерфейсы для
execve()int execl(const char *path, const char *arg, ...)Первый аргумент,
pathargargvargv[0]NULLexecl()environint execlp(const char *file, const char *arg, ...)Эта функция подобна
execl()filePATHfile/PATHexeclp():/bin:/usr/binPATHБолее того, если файл найден и имеет право доступа на исполнение, но не может быть исполнен из-за того, что неизвестен его формат,
execlp()int execle(const char *path, const char *arg, ..., char *const envp[])Эта функция также подобна
execl()envpexecl()envpNULLВторая группа функций-оболочек принимает массив в стиле
argvint execv(const char *path, char *const argv[])Эта функция подобна
execve()int execvp(const char *file, char *const argv[])Эта функция подобна
execv()PATHexeclp()В табл. 9.1 подведены итоги для шести функций
exec()Таблица 9.1. Сводка семейства функций
exec()| Функция | Поиск пути | Окружение пользователя | Назначение |
|---|---|---|---|
|
√ | Исполняет список аргументов. | |
|
Исполняет список аргументов с окружением. | ||
|
√ | √ | Исполняет список аргументов с поиском пути |
|
√ | Исполняет с |
|
|
Исполняет с |
||
|
√ | √ | Исполняет с |
Функций
execlp()execvp()PATH
9.1.4.3. Имена программ и argv[0]
argv[0]До сих пор мы все время считали
argv[0]/Однако, как должно быть ясно к этому времени, то, что
argv[0]argv[0]ch09-run.c1 /* ch09-run.c --- запуск программы с другим именем и любыми аргументами */23 #include 4 #include 5 #include 67 /* main --- настроить argv и запустить указанную программу */89 int main(int argc, char **argv)10 {11 char *path;1213 if (argc < 3) {14 fprintf(stderr, "usage: %s path arg0 [ arg ... ]\n", argv[0]);15 exit(1);16 }1718 path = argv[1];1920 execv(path, argv + 2); /* skip argv[0] and argv[1] */2122 fprintf(stderr, "%s: execv() failed: %s\n", argv[0],23 strerror(errno));24 exit(1);25 }Первый аргумент является путем к запускаемой программе, а второй аргумент является новым именем для программы (которое большинство утилит игнорируют, кроме сообщений об ошибках); все остальные аргументы передаются вызываемой программе.
Строки 13–16 осуществляют проверку ошибок. Строка 18 сохраняет путь в
pathexec$ ch09-run /bin/grep whoami foo /* Запустить grep */a line /* Входная строка не подходит */a line with foo in it /* Входная строка подходит */a line with foo in it /* Это выводится */^D /* EOF */$ ch09-run nonexistent-program foo bar /* Демонстрация неудачи */ch09-run: execv() failed: No such file or directoryСледующий пример несколько неестественен: мы заставили
ch09-runfoo$ ch09-run ./ch09-run foousage: foo path arg() [ arg ... ]Хотя она и не очень полезна,
ch09-runargv[0]В System III (примерно в 1980-м) команды
cplnmv/binargv[0]gmakegawkСегодня также дисковое пространство дешево; если из одного и того же исходного кода можно построить две почти идентичные программы, лучше это сделать, использовав
#ifdefgrepegrep
9.1.4.4. Атрибуты, наследуемые exec()
exec()Как и в случае с
fork()exec• Все открытые файлы и открытые каталоги; см. раздел 4.4.1 «Понятие о дескрипторах файлов» и раздел 3.3.1 «Базовое чтение каталогов». (Сюда не входят файлы, помеченные для закрытия при исполнении (close-on-exec), как описано далее в этой главе; см. раздел 9.4.3.1 «Флаг close-on-exec».)
• Установки umask; см. раздел 4.6 «Создание файлов».
• Текущий рабочий каталог, см. раздел 8.4.1 «Изменение каталога:
chdir()fchdir()• Корневой каталог; см. раздел 8.6 «Изменение корневого каталога:
chroot()• Текущее значение относительного приоритета.
• ID процесса и ID родительского процесса.
• ID группы процесса и контролирующий терминал; см. раздел 9.2.1 «Обзор управления работами».
• Маску сигналов процесса и любые ожидающие сигналы, а также любые не истекшие аварийные сигналы или таймеры (здесь не обсуждается; см. главу 10 «Сигналы»).
• Действительные ID пользователя и ID группы, а также дополнительный набор групп. Эффективные ID пользователя и группы (а следовательно, и сохраненные ID set-user и set-group) могут быть установлены с помощью битов setuid и setgid исполняемого файла. (Ничто из этого пока не обсуждалось; см. главу 11 «Права доступа и ID пользователя и группы».)
• Блокировки файлов сохраняются (также пока не обсуждалось; см. раздел 14.2 «Блокировка файлов»).
• Суммарное использованное время процессора для процесса и его потомков не меняется.
После
execfork()exec()После
execВ большинстве случаев при исполнении
forkexecforkexec
9.1.5. Завершение процесса
Завершение процесса включает два шага: окончание процесса с передачей системе статуса завершения и восстановление информации родительским процессом.
9.1.5.1. Определение статуса завершения процесса
Статус завершения (exit status) (известный также под другими именами значения завершения (exit value), кода возврата (return code) и возвращаемого значения (return value)) представляет собой 8-битовое значение, которое родитель может использовать при завершении порожденного процесса (на языке Unix, «когда порожденный кончается (dies)»). По соглашению статус завершения 0 означает, что программа отработала без проблем. Любое ненулевое значение указывает на какую-нибудь разновидность ошибки; программа определяет используемые числа и их значения, если они есть. (Например,
grep
использует 0 для указания, что образец был встречен по крайней мере один раз, 1 означает, что образец вообще не встретился, а 2 означает, что возникла ошибка.) Этот статус завершения доступен на уровне оболочки (для оболочек в стиле оболочки Борна) через специальную переменную $?
.
Стандарт С определяет две константы, которые следует использовать для полной переносимости на не-POSIX системы:
EXIT_SUCCESS
Программа завершилась без проблем. Для обозначения успеха может также использоваться ноль.
EXIT
_FAILURE
В программе была какая-нибудь проблема.
На практике использование лишь этих значений довольно ограничивает. Вместо этого следует выбрать небольшой набор кодов возврата, документировать их значения и использовать. (Например, 1 для ошибок опций командной строки и аргументов, 2 для ошибок ввода/вывода, 3 для ошибок данных и т.д.) Для удобочитаемости стоит использовать константы
#define
или значения enum
. Слишком большой список ошибок делает их использование обременительным; в большинстве случаев вызывающая программа (или пользователь) интересуется лишь нулевым или ненулевым значением.
Когда достаточно двоичного разделения успех/неудача, педантичный программист использует
EXIT_SUCCESS
и EXIT_FAILURE
. Наш собственный стиль более естественный, используя с return
и exit()
явные константы 0 или 1. Это настолько обычно, что рано заучивается и быстро становится второй натурой. Однако для своих проектов вы сами должны принять решение.
ЗАМЕЧАНИЕ. Для родительского процесса доступны лишь восемь наименее значимых битов значения. Поэтому следует использовать значения в диапазоне 0–255. Как мы вскоре увидим, у чисел 126 и 127 есть традиционные значения (помимо простого «неуспешно»), которых ваши программы должны придерживаться.
Поскольку имеют значение лишь восемь наименее значимых битов, вы никогда не должны использовать отрицательные статусы завершения. Когда из небольших отрицательных чисел выделяются восемь последних битов, они превращаются в большие положительные значения! (Например. -1 становится 255, а -5 становится 251.) Мы видели книги по программированию на С, в которых это понималось неправильно — не дайте сбить себя с толку
9.1.5.2. Возвращение из main()
Программа может естественно завершиться одним из двух способов: посредством использования одной из описанных далее функций или возвратившись из
main()
. (Третий, более радикальный способ описан далее в разделе 12.4 «Совершение самоубийства: abort()
».) В последнем случае следует использовать явное возвращаемое значение вместо выпадения в конце функции:
/* Правильно */ /* Неправильно */
int main(int argc, char **argv) int main(int argc, char **argv)
{ {
/* здесь код */ /* здесь код */
return 0; /* ?? Что возвращает main()? */
} }
Стандарт С 1999 г. указывает, что при выпадении в конце, поведение функции
main()
должно быть таким, как если бы она возвращала 0. (Это верно также для С++; однако, стандарт С 1989 г. намеренно оставляет этот случай неопределенным.) Во всех случаях плохо полагаться на это поведение; однажды вы можете программировать для системы со скудной поддержкой С времени исполнения, или для внедренной системы, или где-то еще, где это будет по-другому. (В общем, выпадение в конце любой функции, не являющейся void
— плохая мысль, которая может вести лишь к ошибочному коду.)
Возвращенное из
main()
значение автоматически передается обратно системе, от которой родительский процесс может его впоследствии получить. Мы опишем, как это делается, в разделе 9.1.6.1 «Использование функций POSIX: wait()
и waitpid()
».
ЗАМЕЧАНИЕ. На системах GNU/Linux управляемая компилятором команда c99 запускает компилятор с соответствующими опциями, так что возвращаемое значение при выпадении из конца функции равно 0. Простой gcc этого не делает.
9.1.5.3. Функции завершения
Другим способом естественного завершения программы является вызов функций завершения. Стандарт С определяет следующие функции:
#include /* ISO С */
void exit(int status);
void _Exit(int status);
int atexit(void (*function)(void));
Эти функции работают следующим образом:
void exit(int status)
Эта функция завершает программу,
status
передается системе для использования родителем. Перед завершением программы exit()
вызывает все функции, зарегистрированные с помощью atexit()
, сбрасывает на диск и закрывает все открытые потоки <stdio.h> FILE
* и удаляет все временные файлы, созданные tmpfile()
(см. раздел 12.3.2 «Создание и открытие временных файлов»). Когда процесс завершается, ядро закрывает любые оставшиеся открытыми файлы (которые были открыты посредством open()
, creat()
или через наследование дескрипторов), освобождает его адресное пространство и освобождает любые другие ресурсы, которые он мог использовать. exit()
никогда не возвращается.
void _Exit(int status)
Эта функция в сущности идентична функции POSIX
_exit()
; мы на короткое время отложим ее обсуждение,
int atexit(void (*function)(void))
function
является указателем на функцию обратного вызова, которая должна вызываться при завершении программы, exit()
запускает функцию обратного вызова перед закрытием файлов и завершением. Идея в том, что приложение может предоставить одну или более функций очистки, которые должны быть запущены перед окончательным завершением работы. Предоставление функции называется ее регистрацией. (Функции обратного вызова для nftw()
обсуждались в разделе 8.4.3.2 «Функция обратного вызова nftw()
»; здесь та же идея, хотя atexit()
вызывает каждую зарегистрированную функцию лишь однажды.)
atexit()
возвращает 0 при успехе или -1 при неудаче и соответствующим образом устанавливает errno
.
Следующая программа не делает полезной работы, но демонстрирует, как работает
atexit()
:
/* ch09-atexit.c --- демонстрация atexit().
Проверка ошибок для краткости опущена. */
/*
* Функции обратного вызова здесь просто отвечают на вызов.
* В настоящем приложении они делали бы больше. */
void callback1(void) { printf("callback1 called\n"); }
void callback2(void) { printf("callback2 called\n"); }
void callback3(void) { printf("callback3 called\n"); }
/* main --- регистрация функций и завершение */
int main(int argc, char **argv) {
printf("registering callback1\n"); atexit(callback1);
printf("registering callback2\n"); atexit(callback2);
printf("registering callback3\n"); atexit(callback3);
printf("exiting now\n");
exit(0);
}
Вот что происходит при запуске:
$ ch09-atexit
registering callback1 /* Запуск главной программы */
registering callback2
registering callback3
exiting now
callback3 called /* Функции обратного вызова запускаются в обратном
порядке */
callback2 called
callback1 called
Как показывает пример, функции, зарегистрированные с помощью
atexit()
, запускаются в порядке, обратном порядку их регистрации: последние первыми. (Это обозначается также LIFO — last-in-first-out — вошедший последним выходит первым).
POSIX определяет функцию
_exit()
. В отличие от exit()
, которая вызывает функции обратного вызова и выполняет
-очистку, _exit()
является «сразу заканчивающейся» функцией:
#include /* POSIX */
void _exit(int status);
Системе передается
status
, как и для exit()
, но процесс завершается немедленно. Ядро все еще делает обычную очистку: все открытые файлы закрываются, использованная адресным пространством память освобождается, любые другие ресурсы, использованные процессом, также освобождаются.
На практике функция
_Exit()
ISO С идентична _exit()
. Стандарт С говорит, что от реализации функции зависит, вызывает ли _Exit()
зарегистрированные atexit()
функции и закрывает ли открытые файлы. Для систем GLIBC это не так, и функция ведет себя подобно _exit()
.
Время использовать
_exit()
наступает, когда exec
в порожденном процессе завершается неудачей. В этом случае вам не нужно использовать обычный exit()
, поскольку это сбрасывает на диск данные буферов, хранящиеся в потоках FILE*
. Когда позже родительский процесс сбрасывает на диск свои копии буферов, данные буфера оказываются записанными дважды; это очевидно нехорошо.
Например, предположим, что вы хотите запустить команду оболочки и хотите сами выполнить
fork
и exec
. Такой код выглядел бы следующим образом:
char *shellcommand = "...";
pid_t child;
if ((child = fork()) == 0) { /* порожденный процесс */
execl("/bin/sh", "sh", "-c", shellcommand, NULL);
_exit(errno == ENOENT ? 127 : 126);
}
/* родитель продолжает */
Проверка значения
errno
и завершающего значения следуют соглашениям, используемым оболочкой POSIX. Если запрошенная программа не существует (ENOENT
— нет для неё элемента в каталоге), завершающее значение равно 127. В противном случае, файл существует, но exec
не могла быть выполнена по какой-то другой причине, поэтому статус завершения равен 126. Хорошая мысль следовать этим соглашениям также и в ваших программах. Вкратце, чтобы хорошо использовать exit()
и atexit()
, следует делать следующее:
• Определить небольшой набор значений статуса завершения, которые ваша программа будет использовать для сообщения этой информации вызывающему. Используйте для них в своем коде константы
#define
или enum
.
• Решить, имеет ли смысл наличие функций обратного вызова для использования с
atexit()
. Если имеет, зарегистрировать их в main()
в соответствующий момент; например, после анализа опций и инициализации всех структур данных, которые функция обратного вызова должна очищать. Помните, что функции должны вызываться в порядке LIFO (последняя вызывается первой).
• Использовать
exit()
для выхода из программы во всех местах, когда что-то идет не так и когда выход является правильным действием. Используйте коды ошибок, которые определили.
• Исключением является
main()
, для которой можно использовать при желании return
. Наш собственный стиль заключается обычно в использовании exit()
при наличии проблем и 'return 0
' в конце main()
, если все прошло хорошо.
• Использовать
_exit()
или _Exit()
в порожденном процессе, если exec() завершается неудачей.
Завершение процесса включает два шага: окончание процесса с передачей системе статуса завершения и восстановление информации родительским процессом.
9.1.5.1. Определение статуса завершения процесса
Статус завершения (exit status) (известный также под другими именами значения завершения (exit value), кода возврата (return code) и возвращаемого значения (return value)) представляет собой 8-битовое значение, которое родитель может использовать при завершении порожденного процесса (на языке Unix, «когда порожденный кончается (dies)»). По соглашению статус завершения 0 означает, что программа отработала без проблем. Любое ненулевое значение указывает на какую-нибудь разновидность ошибки; программа определяет используемые числа и их значения, если они есть. (Например,
grep$?Стандарт С определяет две константы, которые следует использовать для полной переносимости на не-POSIX системы:
EXIT_SUCCESSПрограмма завершилась без проблем. Для обозначения успеха может также использоваться ноль.
EXITВ программе была какая-нибудь проблема.
На практике использование лишь этих значений довольно ограничивает. Вместо этого следует выбрать небольшой набор кодов возврата, документировать их значения и использовать. (Например, 1 для ошибок опций командной строки и аргументов, 2 для ошибок ввода/вывода, 3 для ошибок данных и т.д.) Для удобочитаемости стоит использовать константы
#defineenumКогда достаточно двоичного разделения успех/неудача, педантичный программист использует
EXIT_SUCCESSEXIT_FAILUREreturnexit()ЗАМЕЧАНИЕ. Для родительского процесса доступны лишь восемь наименее значимых битов значения. Поэтому следует использовать значения в диапазоне 0–255. Как мы вскоре увидим, у чисел 126 и 127 есть традиционные значения (помимо простого «неуспешно»), которых ваши программы должны придерживаться.
Поскольку имеют значение лишь восемь наименее значимых битов, вы никогда не должны использовать отрицательные статусы завершения. Когда из небольших отрицательных чисел выделяются восемь последних битов, они превращаются в большие положительные значения! (Например. -1 становится 255, а -5 становится 251.) Мы видели книги по программированию на С, в которых это понималось неправильно — не дайте сбить себя с толку
9.1.5.2. Возвращение из main()
main()Программа может естественно завершиться одним из двух способов: посредством использования одной из описанных далее функций или возвратившись из
main()abort()/* Правильно */ /* Неправильно */int main(int argc, char **argv) int main(int argc, char **argv){ { /* здесь код */ /* здесь код */ return 0; /* ?? Что возвращает main()? */} }Стандарт С 1999 г. указывает, что при выпадении в конце, поведение функции
main()voidВозвращенное из
main()wait()waitpid()ЗАМЕЧАНИЕ. На системах GNU/Linux управляемая компилятором команда c99 запускает компилятор с соответствующими опциями, так что возвращаемое значение при выпадении из конца функции равно 0. Простой gcc этого не делает.
9.1.5.3. Функции завершения
Другим способом естественного завершения программы является вызов функций завершения. Стандарт С определяет следующие функции:
#include /* ISO С */ void exit(int status);void _Exit(int status);int atexit(void (*function)(void));Эти функции работают следующим образом:
void exit(int status)Эта функция завершает программу,
statusexit()atexit()stdio.h> FILEtmpfile()open()creat()exit()void _Exit(int status)Эта функция в сущности идентична функции POSIX
_exit()int atexit(void (*function)(void))functionexit()nftw()nftw()atexit()atexit()errnoСледующая программа не делает полезной работы, но демонстрирует, как работает
atexit()/* ch09-atexit.c --- демонстрация atexit(). Проверка ошибок для краткости опущена. *//* * Функции обратного вызова здесь просто отвечают на вызов. * В настоящем приложении они делали бы больше. */void callback1(void) { printf("callback1 called\n"); }void callback2(void) { printf("callback2 called\n"); }void callback3(void) { printf("callback3 called\n"); }/* main --- регистрация функций и завершение */int main(int argc, char **argv) { printf("registering callback1\n"); atexit(callback1); printf("registering callback2\n"); atexit(callback2); printf("registering callback3\n"); atexit(callback3); printf("exiting now\n"); exit(0);}Вот что происходит при запуске:
$ ch09-atexitregistering callback1 /* Запуск главной программы */registering callback2registering callback3exiting nowcallback3 called /* Функции обратного вызова запускаются в обратном порядке */callback2 calledcallback1 calledКак показывает пример, функции, зарегистрированные с помощью
atexit()POSIX определяет функцию
_exit()exit()_exit()#include /* POSIX */ void _exit(int status);Системе передается
statusexit()На практике функция
_Exit()_exit()_Exit()atexit()_exit()Время использовать
_exit()execexit()FILE*Например, предположим, что вы хотите запустить команду оболочки и хотите сами выполнить
forkexecchar *shellcommand = "...";pid_t child;if ((child = fork()) == 0) { /* порожденный процесс */ execl("/bin/sh", "sh", "-c", shellcommand, NULL); _exit(errno == ENOENT ? 127 : 126);}/* родитель продолжает */Проверка значения
errnoENOENTexecexit()atexit()• Определить небольшой набор значений статуса завершения, которые ваша программа будет использовать для сообщения этой информации вызывающему. Используйте для них в своем коде константы
#defineenum• Решить, имеет ли смысл наличие функций обратного вызова для использования с
atexit()main()• Использовать
exit()• Исключением является
main()returnexit()return 0main()• Использовать
_exit()_Exit()
9.1.6. Использование статуса завершения порожденного процесса
Когда процесс заканчивается, нормальным ходом событий для ядра является освобождение всех его ресурсов. Ядро сохраняет статус завершения законченного процесса, также, как сведения о ресурсах, которые он использовал в своей работе, a PID продолжает считаться используемым. Такой завершившийся процесс называется зомби.
Родительский процесс, будь то первоначальный родитель или
init
, может получить статус завершения порожденного процесса. Или, посредством использования функций BDS, которые не стандартизованы POSIX, можно получить статус завершения вместе со сведениями об использовании ресурсов. Использование статуса осуществляется ожиданием окончания процесса: это известно также как пожинание (reaping) процесса[91].
Между механизмами, которые ожидают завершения потомков, и сигнальными механизмами, которые мы еще не обсуждали, есть значительное взаимодействие. Что из них описать вначале представляет собой нечто вроде проблемы курицы и яйца; мы решили сначала поговорить сначала о механизмах ожидания порожденного процесса, а глава 10 «Сигналы» дает полный рассказ о сигналах.
Пока достаточно понять, что сигнал является способом уведомления процесса о том, что произошло некоторое событие. Процессы могут генерировать сигналы, которые посылаются самим себе, или сигналы могут посылаться извне другими процессами или пользователем за терминалом. Например, CTRL-C посылает сигнал «прерывания», a CTRL-Z посылает сигнал управления работой «стоп».
По умолчанию, многие сигналы, такие, как сигнал прерывания, заставляют получающий процесс закончиться. Другие, такие, как сигналы управления работами, вызывают изменение его состояния. Механизмы ожидания порожденного процесса могут определить, претерпел ли процесс сигнал завершения, и если да, какой это был сигнал. То же верно и для остановки процесса и, на некоторых системах возобновления процесса.
9.1.6.1. Использование функций POSIX: wait()
и waitpid()
Первоначальным системным вызовом V7 был
wait()
. Более новым вызовом POSIX, основанным на возможностях BSD, является waitpid()
. Объявления функций следующие:
#include /* POSIX */
#include
pid_t wait(int *status);
pid_t waitpid(pid_t pid, int *status, int options);
wait()
ждет завершения любого порожденного процесса; сведения о том, как он завершился, возвращаются в *status
. (Вскоре мы обсудим, как интерпретировать *status
.) Возвращаемое значение является PID завершившегося процесса или -1, если возникла ошибка.
Если порожденных процессов нет,
wait()
возвращает -1 с errno
, установленным в ECHILD
(отсутствует порожденный процесс). В противном случае, функция ждет завершения первого порожденного процесса или поступления сигнала.
Функция
waitpid()
дает возможность ждать завершения определенного порожденного процесса. Она предоставляет значительную гибкость и является предпочтительной для использования функцией. Она также возвращает PID закончившегося процесса или -1 при возникновении ошибки. Аргументы следующие:
pid_t pid
Значение указывает, завершения какого порожденного процесса ждать как по-настоящему
pid
, так и по группе процесса. Смысл значения pid
следующий:
pid < -1
Ждать завершения любого порожденного процесса с ID группы процесса, равной абсолютному значению pid
.
pid = -1
Ждать завершения любого порожденного процесса. Таким способом работает wait()
.
pid = 0
Ждать завершения любого порожденного процесса с ID группы процесса, равной ID группе родительского процесса.
pid > 0
Ждать завершения конкретного процесса с PID, равным pid
.
int *status
То же, что и для
wait()
.
определяет различные макросы, которые интерпретируют значение в *status
, которые мы вскоре опишем
int options
Этот параметр должен быть равен либо 0, либо побитовым ИЛИ одного или более из следующих флагов:
WNOHANG
Если ни один порожденный процесс не завершился, вернуться немедленно. Таким способом можно периодически проверять, не закончился ли какой- нибудь порожденный процесс. (Такая периодическая проверка известна как опрашивание события.)
WUNTRACED
Вернуть сведения о порожденном процессе, который остановился, но еще не завершился. (Например, для управления работой.)
WCONTINUED
(XSI.) Вернуть сведения о порожденном процессе, который продолжился, если его статус не сообщался с момента изменения. Это также для управления работой. Этот флаг является расширением XSI и не доступен под GNU/Linux.
С заполненным значением
*status
работают несколько макросов, определяющие, что случилось. Они имеют тенденцию образовывать пары: один макрос для определения, что что-то случилось, и если этот макрос истинен, еще один макрос позволяет получить подробности. Макросы следующие:
WIFEXITED(status)
Этот макрос не равен нулю (true), если процесс завершился (в противоположность изменению состояния).
WEXITSTATUS(status)
Этот макрос дает статус завершения; он равен восьми наименее значимым битам значения, переданного
exit()
или возвращенного из main()
. Этот макрос следует использовать лишь если WIFEXIDED(status)
равен true.
WIFSIGNALED(status)
Этот макрос не равен нулю, если процесс подвергся действию завершающего сигнала death-by-signal.
WTERMSIG(status)
Этот макрос предоставляет номер сигнала, который завершил процесс. Этот макрос следует использовать, лишь когда
WIFSIGNALED(status)
равен true.
WIFSTOPPED(status)
Этот макрос не равен нулю, если процесс был остановлен.
WSTOPSIG(status)
Этот макрос предоставляет номер сигнала, который остановил процесс. (Процесс остановить могут несколько сигналов.) Этот макрос следует использовать лишь когда
WIFSTOPPED(status)
равен true. Сигналы управления работами обсуждаются в разделе 10.8.2 «Сигналы управления работой».
WIFCONTINUED(status)
(XSI.) Этот макрос не равен нулю, если процесс был продолжен. Соответствующего макроса
WCONTSIG()
нет, поскольку лишь один сигнал может вызвать продолжение процесса.
Обратите внимание, что этот макрос является расширением XSI и в частности, он недоступен в GNU/Linux. Следовательно, если вы хотите его использовать, заключите код внутри '
#ifdef WIFCONTINUED ... #endif
'.
WCOREDUMP(status)
(Общий.) Этот макрос не равен нулю, если процесс создал снимок. Снимок процесса (core dump) является образом запущенного процесса в памяти, созданном при завершении процесса. Он предназначен для использования впоследствии при отладке. Системы Unix называют файл
core
, тогда как системы GNU/Linux используют corе.pid
, где pid
является ID завершившегося процесса. Определенные сигналы завершают процесс и автоматически создают снимок процесса.
Обратите внимание, что этот макрос не стандартный. Системы GNU/Linux, Solaris и BSD его поддерживают, однако некоторые другие системы Unix нет. Поэтому и здесь, если нужно его использовать, заключите код внутрь '
#ifdef WCOREDUMP ... #endif
'.
Большинство программ не интересуются, почему завершился порожденный процесс; им просто нужно, что он завершился, возможно, отметив, было завершение успешным или нет. Программа GNU Coreutils
install
демонстрирует такое простое использование fork()
, execlp()
и wait()
. Опция -s
заставляет install
запустить для устанавливаемого двоичного исполняемого файла программу strip
. (strip
удаляет из исполняемого файла отладочную и прочую информацию. Это может сохранить значительное пространство. На современных системах с многогигабайтными жесткими дисками при установке редко бывает необходимо использовать strip
для исполняемых файлов.) Вот функция strip()
из install.с
:
513 /* Вырезать таблицу имен из файла PATH.
514 Мы могли бы сначала вытащить из файла магическое число
515 для определения, нужно ли вырезать, но заголовочные файлы и
516 магические числа варьируют от системы к системе так сильно, что
517 сделать его переносимым было бы очень трудно. Не стоит усилий. */
518
519 static void
520 strip (const char *path)
521 {
522 int status;
523 pid_t pid = fork();
524
525 switch (pid)
526 {
527 case -1:
528 error(EXIT_FAILURE, errno, _("fork system call failed"));
529 break;
530 case 0: /* Порожденный. */
531 execlp("strip", "strip", path, NULL);
532 error(EXIT_FAILURE, errno, _("cannot run strip"));
533 break;
534 default: /* Родитель. */
535 /* Родительский процесс. */
536 while (pid != wait(&status)) /* Ждать завершения потомка. */
537 /* Ничего не делать. */ ;
538 if (status)
539 error(EXIT_FAILURE, 0, _("strip failed"));
540 break;
541 }
542 }
Строка 523 вызывает
fork()
. Затем оператор switch
предпринимает нужное действие для возвращения ошибки (строки 527–529), порожденного процесса (строки 530–533) и родительского процесса (строки 534–539).
Стиль строк 536–537 типичен; они ожидают завершения нужного порожденного процесса. Возвращаемое значение wa
it()
является PID этого потомка. Оно сравнивается с PID порожденного процесса, status
проверяется лишь на предмет равенства нулю (строка 538), в случае ненулевого результата потомок завершился неудачно. (Тест, хотя и правильный, грубый, но простой. Более правильным был бы тест наподобие 'if (WIFEXITED(status) && WEXITSTATUS(status) != 0)
'.)
Из описаний и кода, представленных до сих пор, может показаться, что родительские программы должны выбрать определенный момент, чтобы ожидать завершения любого порожденного процесса, возможно, с опросом в цикле (как делает
install.c
), ожидая всех потомков. В разделе 10.8.3 «Родительский надзор: три различные стратегии» мы увидим, что это необязательно. Скорее, сигналы предоставляют ряд механизмов для использования уведомлениями родителей о завершении порожденных процессов.
9.1.6.2. Использование функций BSD: wait3()
и wait4()
Системные вызовы BSD
wait3()
и wait4()
полезны, если вы интересуетесь ресурсами, использованными порожденным процессом. Функции нестандартны (что означает, что они не являются частью POSIX), но широко доступны, в том числе на GNU/Linux. Объявления следующие:
#include /* Обычный */
#include
/* Под GNU/Linux не нужно, но улучшает переносимость */
#include
#include
pid_t wait3(int *status, int options, struct rusage *rusage);
pid_t wait4(pid_t pid, int *status, int options, struct rusage *rusage);
Переменная
status
та же, что и для wait()
и waitpid()
. Все описанные ранее макросы (WIFEXITED()
и т.д.) могут использоваться и с ними.
Значение
options
также то же самое, что и для waitpid()
: либо 0, либо побитовое ИЛИ с одним или обоими флагами WNOHANG
и WUNTRACED
.
wait3()
ведет себя подобно wait()
, получая сведения о первом доступном порожденном зомби, a wait4()
подобна waitpid()
, получая сведения об определенном процессе. Обе функции возвращают PID потомка, -1 при ошибке или 0, если нет доступных процессов и был использован флаг WNOHANG
. Аргумент pid
может принимать те же значения, что и аргумент pid
для waitpid()
.
Ключевым отличием является указатель
struct rusage
. Если он не равен NULL
, система заполняет ее сведениями о процессе. Эта структура описана в POSIX и в справочной странице getrusage(2):
struct rusage {
struct timeval ru_utime; /* используемое время пользователя */
struct timeval ru_stime; /* используемое системное время */
long ru_maxrss; /* максимальный размер резидентного набора */
long ru_ixrss; /* общий размер разделяемой памяти */
long ru_idrss; /* общий размер не разделяемых данных */
long ru_isrss; /* общий размер не разделяемого стека */
long ru_minflt; /* использование страниц */
long ru_majflt; /* ошибок страниц */
long ru_nswap; /* подкачек */
long ru_inblock; /* блочных операций ввода */
long ru_oublock; /* блочных операций вывода */
long ru_msgsnd; /* посланных сообщений */
long ru_msgrcv; /* полученных сообщений */
long ru_nsignals; /* полученных сигналов */
long ru_nvcsw; /* добровольных переключений контекста */
long ru_nivcsw; /* принудительных переключений контекста */
};
Чисто BSD системы (4.3 Reno и более поздние) поддерживают все поля. В табл. 9.2 описаны доступность различных полей
struct rusage
для POSIX и Linux.
Таблица 9.2. Доступность полей
struct rusage
Поле
POSIX
Linux
Поле
POSIX
Linux
ru_utime
√
≥ 2.4
ru_nswap
≥2.4
ru_stime
√
≥2.4
ru_nvcsw
≥2.6
ru_minflt
≥2.4
ru_nivcsw
≥2.6
ru_majflt
≥2.4
Стандартом определены лишь поля, помеченные «POSIX». Хотя Linux определяет полную структуру, ядро 2.4 поддерживает лишь поля времени пользователя и системного времени. Ядро 2.6 поддерживает также поля, связанные с переключением контекста.[92]
Наиболее интересными полями являются
ru_utime
и ru_stime
, использование времени процессора в режиме пользователя и ядра соответственно. (Время процессора в режиме пользователя является временем, потраченным на исполнение кода уровня пользователя. Время процессора в режиме ядра является временем, потраченным в ядре в пользу процесса.)
Эти два поля используют
struct timeval
, которая содержит значения времени с точностью до микросекунд. Дополнительные сведения по этой структуре см. в разделе 14.3.1 «Время в микросекундах: gettimeofday()
».
В 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()
».
Когда процесс заканчивается, нормальным ходом событий для ядра является освобождение всех его ресурсов. Ядро сохраняет статус завершения законченного процесса, также, как сведения о ресурсах, которые он использовал в своей работе, a PID продолжает считаться используемым. Такой завершившийся процесс называется зомби.
Родительский процесс, будь то первоначальный родитель или
initМежду механизмами, которые ожидают завершения потомков, и сигнальными механизмами, которые мы еще не обсуждали, есть значительное взаимодействие. Что из них описать вначале представляет собой нечто вроде проблемы курицы и яйца; мы решили сначала поговорить сначала о механизмах ожидания порожденного процесса, а глава 10 «Сигналы» дает полный рассказ о сигналах.
Пока достаточно понять, что сигнал является способом уведомления процесса о том, что произошло некоторое событие. Процессы могут генерировать сигналы, которые посылаются самим себе, или сигналы могут посылаться извне другими процессами или пользователем за терминалом. Например, CTRL-C посылает сигнал «прерывания», a CTRL-Z посылает сигнал управления работой «стоп».
По умолчанию, многие сигналы, такие, как сигнал прерывания, заставляют получающий процесс закончиться. Другие, такие, как сигналы управления работами, вызывают изменение его состояния. Механизмы ожидания порожденного процесса могут определить, претерпел ли процесс сигнал завершения, и если да, какой это был сигнал. То же верно и для остановки процесса и, на некоторых системах возобновления процесса.
9.1.6.1. Использование функций POSIX: wait()
и waitpid()
wait()waitpid()Первоначальным системным вызовом V7 был
wait()waitpid()#include /* POSIX */ #include pid_t wait(int *status);pid_t waitpid(pid_t pid, int *status, int options);wait()*status*statusЕсли порожденных процессов нет,
wait()errnoECHILDФункция
waitpid()pid_t pidЗначение указывает, завершения какого порожденного процесса ждать как по-настоящему
pidpidpid < -1 pidpid = -1 wait()pid = 0 pid > 0 pidint *statusТо же, что и для
wait()*statusint optionsЭтот параметр должен быть равен либо 0, либо побитовым ИЛИ одного или более из следующих флагов:
WNOHANGЕсли ни один порожденный процесс не завершился, вернуться немедленно. Таким способом можно периодически проверять, не закончился ли какой- нибудь порожденный процесс. (Такая периодическая проверка известна как опрашивание события.)
WUNTRACEDВернуть сведения о порожденном процессе, который остановился, но еще не завершился. (Например, для управления работой.)
WCONTINUED(XSI.) Вернуть сведения о порожденном процессе, который продолжился, если его статус не сообщался с момента изменения. Это также для управления работой. Этот флаг является расширением XSI и не доступен под GNU/Linux.
С заполненным значением
*statusWIFEXITED(status)Этот макрос не равен нулю (true), если процесс завершился (в противоположность изменению состояния).
WEXITSTATUS(status)Этот макрос дает статус завершения; он равен восьми наименее значимым битам значения, переданного
exit()main()WIFEXIDED(status)WIFSIGNALED(status)Этот макрос не равен нулю, если процесс подвергся действию завершающего сигнала death-by-signal.
WTERMSIG(status)Этот макрос предоставляет номер сигнала, который завершил процесс. Этот макрос следует использовать, лишь когда
WIFSIGNALED(status)WIFSTOPPED(status)Этот макрос не равен нулю, если процесс был остановлен.
WSTOPSIG(status)Этот макрос предоставляет номер сигнала, который остановил процесс. (Процесс остановить могут несколько сигналов.) Этот макрос следует использовать лишь когда
WIFSTOPPED(status)WIFCONTINUED(status)(XSI.) Этот макрос не равен нулю, если процесс был продолжен. Соответствующего макроса
WCONTSIG()Обратите внимание, что этот макрос является расширением XSI и в частности, он недоступен в GNU/Linux. Следовательно, если вы хотите его использовать, заключите код внутри '
#ifdef WIFCONTINUED ... #endifWCOREDUMP(status)(Общий.) Этот макрос не равен нулю, если процесс создал снимок. Снимок процесса (core dump) является образом запущенного процесса в памяти, созданном при завершении процесса. Он предназначен для использования впоследствии при отладке. Системы Unix называют файл
corecorе.pidpidОбратите внимание, что этот макрос не стандартный. Системы GNU/Linux, Solaris и BSD его поддерживают, однако некоторые другие системы Unix нет. Поэтому и здесь, если нужно его использовать, заключите код внутрь '
#ifdef WCOREDUMP ... #endifБольшинство программ не интересуются, почему завершился порожденный процесс; им просто нужно, что он завершился, возможно, отметив, было завершение успешным или нет. Программа GNU Coreutils
installfork()execlp()wait()-sinstallstrip(stripstripstrip()install.с513 /* Вырезать таблицу имен из файла PATH.514 Мы могли бы сначала вытащить из файла магическое число515 для определения, нужно ли вырезать, но заголовочные файлы и516 магические числа варьируют от системы к системе так сильно, что517 сделать его переносимым было бы очень трудно. Не стоит усилий. */518519 static void520 strip (const char *path)521 {522 int status;523 pid_t pid = fork();524525 switch (pid)526 {527 case -1:528 error(EXIT_FAILURE, errno, _("fork system call failed"));529 break;530 case 0: /* Порожденный. */531 execlp("strip", "strip", path, NULL);532 error(EXIT_FAILURE, errno, _("cannot run strip"));533 break;534 default: /* Родитель. */535 /* Родительский процесс. */536 while (pid != wait(&status)) /* Ждать завершения потомка. */537 /* Ничего не делать. */ ;538 if (status)539 error(EXIT_FAILURE, 0, _("strip failed"));540 break;541 }542 }Строка 523 вызывает
fork()switchСтиль строк 536–537 типичен; они ожидают завершения нужного порожденного процесса. Возвращаемое значение wa
it()statusif (WIFEXITED(status) && WEXITSTATUS(status) != 0)Из описаний и кода, представленных до сих пор, может показаться, что родительские программы должны выбрать определенный момент, чтобы ожидать завершения любого порожденного процесса, возможно, с опросом в цикле (как делает
install.c
9.1.6.2. Использование функций BSD: wait3()
и wait4()
wait3()wait4()Системные вызовы BSD
wait3()wait4()#include /* Обычный */ #include /* Под GNU/Linux не нужно, но улучшает переносимость */#include #include pid_t wait3(int *status, int options, struct rusage *rusage);pid_t wait4(pid_t pid, int *status, int options, struct rusage *rusage);Переменная
statuswait()waitpid()WIFEXITED()Значение
optionswaitpid()WNOHANGWUNTRACEDwait3()wait()wait4()waitpid()WNOHANGpidpidwaitpid()Ключевым отличием является указатель
struct rusageNULLstruct rusage { struct timeval ru_utime; /* используемое время пользователя */ struct timeval ru_stime; /* используемое системное время */ long ru_maxrss; /* максимальный размер резидентного набора */ long ru_ixrss; /* общий размер разделяемой памяти */ long ru_idrss; /* общий размер не разделяемых данных */ long ru_isrss; /* общий размер не разделяемого стека */ long ru_minflt; /* использование страниц */ long ru_majflt; /* ошибок страниц */ long ru_nswap; /* подкачек */ long ru_inblock; /* блочных операций ввода */ long ru_oublock; /* блочных операций вывода */ long ru_msgsnd; /* посланных сообщений */ long ru_msgrcv; /* полученных сообщений */ long ru_nsignals; /* полученных сигналов */ long ru_nvcsw; /* добровольных переключений контекста */ long ru_nivcsw; /* принудительных переключений контекста */};Чисто BSD системы (4.3 Reno и более поздние) поддерживают все поля. В табл. 9.2 описаны доступность различных полей
struct rusageТаблица 9.2. Доступность полей
struct rusage| Поле | POSIX | Linux | Поле | POSIX | Linux |
|---|---|---|---|---|---|
|
√ | ≥ 2.4 | |
≥2.4 | |
|
√ | ≥2.4 | |
≥2.6 | |
|
≥2.4 | |
≥2.6 | ||
|
≥2.4 |
Стандартом определены лишь поля, помеченные «POSIX». Хотя Linux определяет полную структуру, ядро 2.4 поддерживает лишь поля времени пользователя и системного времени. Ядро 2.6 поддерживает также поля, связанные с переключением контекста.[92]
Наиболее интересными полями являются
ru_utimeru_stimeЭти два поля используют
struct timevalgettimeofday()В BSD 4.2 и 4.3 аргумент
statuswait()wait3()union waitintWIFEXITED()Таблица 9.3.
union wait| Макрос POSIX | Член объединения | Использование | Значение |
|---|---|---|---|
|
|
|
True при нормальном завершении |
|
|
|
Статус завершения, если не по сигналу |
|
|
|
True, если завершен по сигналу |
|
|
|
Сигнал, вызвавший завершение |
|
|
|
True, если остановлен |
|
|
|
Сигнал, вызвавший остановку |
|
|
|
True, если потомок сделал снимок образа |
POSIX не стандартизует
union waitwait()waitpid()9.2. Группы процессов
Группа процесса является группой связанных процессов, которые в целях управления заданием (job) рассматриваются вместе. Процессы с одним и тем же ID группы процессов являются членами группы процессов, а процесс, PID которого равен ID группы процессов, является лидеров группы процессов. Новые процессы наследуют ID группы процессов своих родительских процессов.
Мы уже видели, что
waitpid()kill()killpg()9.2.1. Обзор управления заданиями
Управление заданиями является сложной темой, той, в которую мы решили не погружаться в данной книге. Однако, здесь приведен краткий концептуальной обзор.
Устройство терминала (физическое или другое) с работающим на нем пользователем называется управляющим терминалом.
Сеанс (session) является коллекцией групп процессов, связанных с управляющим терминалом. На одном терминале имеется лишь один сеанс, с несколькими группами процессов в сеансе. Один процесс назначен лидером сеанса; обычно это оболочка, такая, как Bash,
pdkshzshksh93Каждое задание, запущенное управляющей заданиями оболочкой, будь то простая программа или конвейер, получает отдельный идентификатор группы процессов. Таким способом оболочка может манипулировать заданием как отдельной сущностью, хотя в нем может быть несколько процессов.
Управляющий терминал также имеет связанный с ним идентификатор группы процессов. Когда пользователь набирает специальный символ, такой, как CTRL-C для «прерывания» или CTRL-Z для «остановки», ядро посылает данный сигнал процессам в группе процессов терминала.
Группе процессов, ID которой совпадает с ID управляющего терминала, разрешено записывать в терминал и читать с него. Эта группа называется приоритетной (foreground) группой процессов. (Она получает также генерируемые клавиатурой сигналы.) Любые другие группы процессов в сеансе являются фоновыми (background) группами процессов и не могут читать или записывать в терминал; они получают специальные сигналы, которые их останавливают, если они пытаются это делать.
Задания переходят из приоритетного режима в фоновый и обратно не путем изменения атрибута задания, но посредством изменения группы процессов управляющего терминала. Это изменение осуществляет именно контролирующая задания оболочка, и если новая группа процессов останавливается, оболочка вновь запускает ее, посылая сигнал «продолжить» всем членам группы процессов.
В былые времена пользователи часто использовали последовательные терминалы, соединенные с модемами, для подключения к централизованным Unix-системам на мини-компьютерах. Когда пользователь закрывал соединение (вешал трубку), линия последовательной передачи обнаруживала отсоединение, и ядро посылало сигнал «отсоединение» всем подключенным к терминалу процессам.
Эта концепция остается: если возникает отключение (оборудование последовательной связи все еще существует и все еще используется), ядро посылает сигнал отсоединения приоритетной группе процессов. Если существует лидер сеанса, происходит то же самое.
Висячая (orphaned) группа процессов — это такая группа, в которой для каждого процесса родительский процесс находится в той же группе или в другом сеансе. (Это может случиться, если управляющая заданиями оболочка завершается при все еще работающих фоновых заданиях.) Запущенным процессам в висячей группе процессов разрешается работать до завершения. Если в такой группе на момент, когда она становится висячей, уже имеются остановленные процессы, ядро посылает этим процессам сигнал отсоединения, а затем сигнал продолжения. Это заставляет их пробудиться, чтобы они могли завершиться, вместо того, чтобы остаться остановленными навечно.
9.2.2. Идентификация группы процессов: getpgrp()
и getpgid()
getpgrp()getpgid()Для совместимости с более старыми системами POSIX предоставляет множество способов получения сведений о группе процессов:
#include pid_t getpgrp(void); /* POSIX */pid_t getpgid(pid_t pid); /* XSI */Функция
getpgrp()getpgid()pidpidgetpgid(0)getpgrp()getpgrp()В BSD 4.2 и 4.3 также есть функция
getpgrp()getpgid()pid
9.2.3. Установка группы процесса: setpgid()
и setpgrp()
setpgid()setpgrp()Две функции устанавливают группу процесса:
#include int setpgid(pid_t pid, pid_t pgid); /* POSIX */int setpgrp(void); /* XSI */Функция
setpgrp()Функция
setpgid()execforkexecПри использовании
setpgid() pgidpidpgidpidИмеется несколько значений для особых случаев как для
pidpgidpid = 0 setpgid()pgidsetpgid(getpid(), pgid)pgid = 0 setpgid(pid, 0)setpgid(pid, pid)pidВо всех случаях лидеры сеанса являются особыми; их PID, ID группы процессов и ID сеанса идентичны, a ID группы процессов лидера не может быть изменена. (ID сеанса устанавливаются посредством
setsid()getsid()9.3. Базовое межпроцессное взаимодействие: каналы и очереди FIFO
Межпроцессное взаимодействие (Interprocess communication — IPC) соответствует своему названию: это способ взаимодействия для двух отдельных процессов. Самым старым способом IPC на системах Unix является канал (pipe): односторонняя линия связи. Данные, записанные в один конец канала, выходят из другого конца.
9.3.1. Каналы
Каналы проявляют себя как обычные дескрипторы файлов. Без особого разбирательства вы не можете сказать, представляет ли дескриптор файла сам файл или канал. Это особенность; программы, которые читают из стандартного ввода и записывают в стандартный вывод, не должны знать или заботиться о том, что они могут взаимодействовать с другим процессом. Если хотите знать, каноническим способом проверки этого является попытка выполнить с дескриптором '
lseek(fd, 0L, SEEK_CUR)
'; этот вызов пытается отсчитать 0 байтов от текущего положения, т е. операция, которая ничего не делает[94]. Эта операция завершается неудачей для каналов и не наносит никакого вреда другим файлам.
9.3.1.1. Создание каналов
Системный вызов
pipe()
создает канал:
#include /* POSIX */
int pipe(int filedes[2]);
Значение аргумента является адресом массива из двух элементов целого типа,
pipe()
возвращает 0 при успешном возвращении и -1, если была ошибка.
Если вызов был успешным, у процесса теперь есть два дополнительных открытых дескриптора файла. Значение
filedes[0]
является читаемым концом канала, a filedes [1]
— записываемым концом. (Удобным мнемоническим способом запоминания является то, что читаемый конец использует индекс 0, аналогичный дескриптору стандартного ввода 0, а записываемый конец использует индекс 1, аналогичный дескриптору стандартного вывода 1.)
Как упоминалось, данные, записанные в записываемый конец, считываются из читаемого конца. После завершения работы с каналом оба конца закрываются с помощью вызова
close()
. Следующая простая программа, ch09-pipedemo.c
, демонстрирует каналы путем создания канала, записи в него данных, а затем чтения этих данных из него:
1 /* ch09-pipedemo.c --- демонстрация ввода/вывода с каналом. */
2
3 #include
4 #include
5 #include
6
7 /* main --- создание канала, запись в него и чтение из него. */
8
9 int main(int argc, char **argv)
10 {
11 static const char mesg[] = "Don't Panic!"; /* известное сообщение */
12 char buf[BUFSIZ];
13 ssize_t rcount, wcount;
14 int pipefd[2];
15 size_t l;
16
17 if (pipe(pipefd) < 0) {
18 fprintf(stderr, "%s: pipe failed: %s\n", argv[0],
19 strerror(errno));
20 exit(1);
21 }
22
23 printf("Read end = fd %d, write end = fd %d\n",
24 pipefd[0], pipefd[1]);
25
26 l = strlen(mesg);
27 if ((wcount = write(pipefd[1], mesg, 1)) != 1) {
28 fprintf(stderr, "%s: write failed: %s\n", argv[0],
29 strerror(errno));
30 exit(1);
31 }
32
33 if ((rcount = read(pipefd[0], buf, BUFSIZ)) != wcount) {
34 fprintf(stderr, "%s: read failed: %s\n", argv[0],
35 strerror(errno));
36 exit(1);
37 }
38
39 buf[rcount] = '\0';
40
41 printf("Read <%s> from pipe\n", buf);
42 (void)close(pipefd[0]);
43 (void)close(pipefd[1]);
44
45 return 0;
46 }
Строки 11–15 объявляют локальные переменные; наибольший интерес представляет
mesg
, который представляет текст, проходящий по каналу.
Строки 17–21 создают канал с проверкой ошибок; строки 23–24 выводят значения новых дескрипторов файлов (просто для подтверждения, что они не равны 0, 1 или 2)
В строке 26 получают длину сообщения для использования с
write()
. Строки 27–31 записывают сообщение в канал, снова с проверкой ошибок.
Строки 33–37 считывают содержимое канала, опять с проверкой ошибок. Строка 39 предоставляет завершающий нулевой байт, так что прочитанные данные могут использоваться в качестве обычной строки. Строка 41 выводит данные, а строки 42–43 закрывают оба конца канала. Вот что происходит при запуске программы:
$ ch09-pipedemo
Read end = fd 3, write end = fd 4
Read from pipe
Эта программа не делает ничего полезного, но она демонстрирует основы. Обратите внимание, что нет вызовов
open()
или creat()
и что программа не использует три своих унаследованных дескриптора. Тем не менее, write()
и read()
завершаются успешно, показывая, что дескрипторы файлов действительны и что данные, поступающие в канал, действительно выходят из него.[95] Конечно, будь сообщение слишком большим, наша программа не работала бы. Это происходит из-за того, что размер (памяти) каналов ограничен, факт, который мы обсудим в следующем разделе.
Подобно другим дескрипторам файлов, дескрипторы для каналов наследуются порожденным процессом после
fork
, и если они не закрываются, все еще доступны после exec
. Вскоре мы увидим, как использовать это обстоятельство и сделать с каналами что-то интересное.
9.3.1.2. Буферирование каналов
Каналы буферируют свои данные, что означает, что записанные в канал данные хранятся ядром до тех пор, пока не будут прочитаны. Однако, канал может содержать лишь такое-то количество записанных, но еще не прочитанных данных. Мы можем называть записывающий процесс производителем, а читающий процесс потребителем. Как система управляет полными и пустыми каналами?
Когда канал полон, система автоматически блокирует производителя в следующий раз, когда он пытается осуществить запись данных в канал с помощью
write()
. Когда канал освобождается, система копирует данные в канал, а затем позволяет системному вызову write()
вернуться к производителю.
Подобным же образом, если канал пустой, потребитель блокируется в
read()
до тех пор, пока в канале не появятся данные для чтения. (Блокирующее поведение можно отключить; это обсуждается в разделе 9.4.3.4 «Неблокирующий ввод/вывод для каналов и очередей FIFO».)
Когда производитель вызывает на записывающем конце канала
close()
, потребитель может успешно прочесть любые данные, все еще находящиеся в канале. После этого дальнейшие вызовы read()
возвращают 0, указывая на конец файла.
Напротив, если потребитель закрывает читаемый конец,
write()
на записываемом конце завершается неудачей. В частности, ядро посылает производителю сигнал «нарушенный канал», действием по умолчанию для которого является завершение процесса.
Нашей любимой аналогией для каналов является то, как муж и жена вместе моют и сушат тарелки. Один супруг моет тарелки, помещая чистые, но влажные тарелки в сушилку на раковине. Другой супруг вынимает тарелки из сушилки и вытирает их. Моющий тарелки является производителем, сушилка является каналом, а вытирающий является потребителем.[96]
Если вытирающий супруг оказывается быстрее моющего, сушилка становится пустой, и вытирающему приходится ждать, пока не будут готовы новые тарелки. Напротив, если быстрее вытирающий супруг, сушилка наполняется, и моющему приходится ждать, пока она не опустеет, прежде чем помещать в нее тарелки. Это изображено на рис. 9.3.
Рис. 9.3. Синхронизация процессов канала
Каналы проявляют себя как обычные дескрипторы файлов. Без особого разбирательства вы не можете сказать, представляет ли дескриптор файла сам файл или канал. Это особенность; программы, которые читают из стандартного ввода и записывают в стандартный вывод, не должны знать или заботиться о том, что они могут взаимодействовать с другим процессом. Если хотите знать, каноническим способом проверки этого является попытка выполнить с дескриптором '
lseek(fd, 0L, SEEK_CUR)9.3.1.1. Создание каналов
Системный вызов
pipe()#include /* POSIX */ int pipe(int filedes[2]);Значение аргумента является адресом массива из двух элементов целого типа,
pipe()Если вызов был успешным, у процесса теперь есть два дополнительных открытых дескриптора файла. Значение
filedes[0]filedes [1]Как упоминалось, данные, записанные в записываемый конец, считываются из читаемого конца. После завершения работы с каналом оба конца закрываются с помощью вызова
close()ch09-pipedemo.c1 /* ch09-pipedemo.c --- демонстрация ввода/вывода с каналом. */23 #include 4 #include 5 #include 67 /* main --- создание канала, запись в него и чтение из него. */89 int main(int argc, char **argv)10 {11 static const char mesg[] = "Don't Panic!"; /* известное сообщение */12 char buf[BUFSIZ];13 ssize_t rcount, wcount;14 int pipefd[2];15 size_t l;1617 if (pipe(pipefd) < 0) {18 fprintf(stderr, "%s: pipe failed: %s\n", argv[0],19 strerror(errno));20 exit(1);21 }2223 printf("Read end = fd %d, write end = fd %d\n",24 pipefd[0], pipefd[1]);2526 l = strlen(mesg);27 if ((wcount = write(pipefd[1], mesg, 1)) != 1) {28 fprintf(stderr, "%s: write failed: %s\n", argv[0],29 strerror(errno));30 exit(1);31 }3233 if ((rcount = read(pipefd[0], buf, BUFSIZ)) != wcount) {34 fprintf(stderr, "%s: read failed: %s\n", argv[0],35 strerror(errno));36 exit(1);37 }3839 buf[rcount] = '\0';4041 printf("Read <%s> from pipe\n", buf);42 (void)close(pipefd[0]);43 (void)close(pipefd[1]);4445 return 0;46 }Строки 11–15 объявляют локальные переменные; наибольший интерес представляет
mesgСтроки 17–21 создают канал с проверкой ошибок; строки 23–24 выводят значения новых дескрипторов файлов (просто для подтверждения, что они не равны 0, 1 или 2)
В строке 26 получают длину сообщения для использования с
write()Строки 33–37 считывают содержимое канала, опять с проверкой ошибок. Строка 39 предоставляет завершающий нулевой байт, так что прочитанные данные могут использоваться в качестве обычной строки. Строка 41 выводит данные, а строки 42–43 закрывают оба конца канала. Вот что происходит при запуске программы:
$ ch09-pipedemoRead end = fd 3, write end = fd 4Read from pipe Эта программа не делает ничего полезного, но она демонстрирует основы. Обратите внимание, что нет вызовов
open()creat()write()read()Подобно другим дескрипторам файлов, дескрипторы для каналов наследуются порожденным процессом после
forkexec9.3.1.2. Буферирование каналов
Каналы буферируют свои данные, что означает, что записанные в канал данные хранятся ядром до тех пор, пока не будут прочитаны. Однако, канал может содержать лишь такое-то количество записанных, но еще не прочитанных данных. Мы можем называть записывающий процесс производителем, а читающий процесс потребителем. Как система управляет полными и пустыми каналами?
Когда канал полон, система автоматически блокирует производителя в следующий раз, когда он пытается осуществить запись данных в канал с помощью
write()write()Подобным же образом, если канал пустой, потребитель блокируется в
read()Когда производитель вызывает на записывающем конце канала
close()read()Напротив, если потребитель закрывает читаемый конец,
write()Нашей любимой аналогией для каналов является то, как муж и жена вместе моют и сушат тарелки. Один супруг моет тарелки, помещая чистые, но влажные тарелки в сушилку на раковине. Другой супруг вынимает тарелки из сушилки и вытирает их. Моющий тарелки является производителем, сушилка является каналом, а вытирающий является потребителем.[96]
Если вытирающий супруг оказывается быстрее моющего, сушилка становится пустой, и вытирающему приходится ждать, пока не будут готовы новые тарелки. Напротив, если быстрее вытирающий супруг, сушилка наполняется, и моющему приходится ждать, пока она не опустеет, прежде чем помещать в нее тарелки. Это изображено на рис. 9.3.
Рис. 9.3. Синхронизация процессов канала
9.3.2. Очереди FIFO
Для традиционных каналов единственным способом для двух различных программ получить доступ к одному и тому же каналу является наследование дескрипторов файлов. Это означает, что процессы должны быть порожденными от общего родителя или один должен быть предком другого.
Это может быть серьезным ограничением. Многие системные службы запускаются как демоны, отсоединенные долгоживущие процессы. Должен быть способ отправки данных таким процессам (и, возможно, получения данных от них). Файлы для этого не подходят; синхронизация трудна или невозможна, а каналы для выполнения задания не могут быть созданы, поскольку нет общих предков.
Для решения этой проблемы System III предложила идею о FIFO. FIFO,[97] или именованный канал, является файлом в файловой системе, который действует подобно каналу. Другими словами, один процесс открывает FIFO для записи, тогда как другой открывает его для чтения. Затем данные, записанные; в FIFO, читаются читателем. Данные буферируются ядром, а не хранятся на диске.
Рассмотрите спулер печати. Демон спулера управляет физическими принтерами, создавая задания для печати и печатая по одному заданию за раз. Для добавления в очередь задания программное обеспечение принтера на уровне пользователя должно сообщаться с демоном спулера. Одним способом для осуществления этого является создание спулером FIFO с хорошо известным именем файла. Программа пользователя может затем открыть FIFO, записать в него запрос и снова закрыть. Спулер находится в цикле, читая запросы из FIFO и обрабатывая их.
Функция mkfifo() создает файлы FIFO:
#include /* POSIX */ #include int mkfifo(const char *pathname, mode_t mode);Аргумент
pathnamemodecreat()open()remove()unlink()Справочная страница GNU/Linux mkfifo(3) указывает, что FIFO должен быть открыт как для чтения, так и для записи в одно и то же время, до того, как может быть осуществлен ввод/вывод: «Открытие FIFO для чтения обычно блокирует до тех пор, пока какой-нибудь другой процесс не откроет тот же FIFO для записи, и наоборот». После открытия файла FIFO он действует подобно обычному каналу; т.е. это просто еще один дескриптор файла.
Команда
mkfifo$ mkfifo afifo /* Создание файла FIFO */$ ls -l afifo /* Показать тип и права доступа, обратите внимание на 'p' впереди */prw-r--r-- 1 arnold devel 0 Oct 23 15:49 afifo$ cat < afifo & /* Запустить читателя в фоновом режиме */[1] 22100$ echo It was a Blustery Day > afifo /* Послать данные в FIFO */$ It was a Blustery Day /* Приглашение оболочки, cat выводит данные */ /* Нажмите ENTER, чтобы увидеть статус завершения задания */[1]+ Done cat 9.4. Управление дескрипторами файлов
На данный момент части загадки почти полностью составлены,
fork()exec()pipe()Системные вызовы
dup()dup2()close()fcntl()
9.4.1. Дублирование открытых файлов: dup()
и dup2()
dup()dup2()Два системных вызова создают копию открытого дескриптора файла:
#include /* POSIX */ int dup(int oldfd);int dup2(int oldfd, int newfd);Функции следующие:
int dup(int oldfd)Возвращает наименьшее значение неиспользуемого дескриптора файла; это копия
oldfddup()int dup2(int oldfd, int newfd)Делает
newfdoldfdnewfdclose()dup2()dup()dup2()Рис. 9.4. Разделение дескриптора файла как результат '
dup2(1, 3)На этом рисунке процесс выполнил '
dup2(1, 3)В разделе 4.4.2 «Открытие и закрытие файлов» мы упомянули, что
open()creat()open()creat()dup2()При наличии правила «возвращения наименьшего неиспользуемого номера» в сочетании с функцией
dup()1. Создать канал с помощью
pipe()2. Создать то, что мы называем «левым потомком». Это процесс, стандартный вывод которого идет в канал. В данном процессе сделать следующее:
a. Использовать '
close(pipefd[0])b. Использовать '
close(1)c. Использовать '
dup(pipefd[1])d. Использовать '
close(pipefd[1])e. Выполнить
exec3. Создать то, что мы называем «правым потомком». Это процесс, стандартный ввод которого поступает из канала. Шаги для этого потомка являются зеркальным отражением шагов для левого потомка:
a. Использовать '
close(pipefd[1])b. Использовать '
close(0)c. Использовать '
dup(pipefd[0])d. Использовать '
close(pipefd[0])e. Выполнить
exec4. В родителе закрыть оба конца канала — '
close(pipefd[0]); close(pipefd[1])5. Наконец, использовать в родителе
wait()Обратите внимание, как важно закрыть неиспользуемые копии дескрипторов файлов каналов. Как мы отмечали ранее, файл не закрывается до тех пор, пока не будет закрыт последний открытый для него дескриптор. Это верно, даже если дескрипторы файлов разделяют несколько процессов. Закрытие не использующихся дескрипторов файлов имеет значение, поскольку процесс, читающий из канала, не получит указания конца файла, пока все копии записываемого конца не будут закрыты.
В нашем случае после порождения двух потомков имеются три процесса, у каждого из которых есть копии двух дескрипторов файлов каналов: родительский и два порожденных. Родительский процесс закрывает оба конца, поскольку ему не нужен канал. Левый потомок записывает в канал, поэтому ему нужно закрыть читаемый конец. Правый потомок читает из канала, поэтому ему нужно закрыть записываемый конец. Это оставляет открытым ровно по одной копии дескриптора файла.
Когда левый потомок завершает работу, он заканчивается. Система после этого закрывает все его дескрипторы файлов. Когда это случается, правый потомок получает в конечном счете уведомление конца файла и тоже может завершить работу и выйти.
Следующая программа,
ch09-pipeline.c$ echo hi there | sed s/hi/hello/ghello thereВот программа:
1 /* ch09-pipeline.c --- ответвляет два процесса в их собственный конвейер.2 Для краткости проверка ошибок сведена к минимуму. */34 #include 5 #include 6 #include 7 #include 8 #include 910 int pipefd[2];1112 extern void left_child(void), right_child(void);1314 /* main --- порождение процессов и ожидание их завершения */1516 int main(int argc, char **argv)17 {18 pid_t left_pid, right_pid;19 pid_t ret;20 int status;2122 if (pipe(pipefd) < 0) { /* создать канал в самом начале */23 perror("pipe");24 exit(1);25 }2627 if ((left_pid = fork()) < 0) { /* порождение левого потомка */28 perror("fork");29 exit(1);30 } else if (left_pid == 0)31 left_child();3233 if ((right_pid = fork()) < 0) { /* порождение правого потомка */34 perror("fork");35 exit(1);36 } else if (right_pid == 0)37 right_child();3839 close(pipefd[0])); /* закрыть родительские копии канала */40 close(pipefd[1]);4142 while ((ret = wait(&status)) > 0) { /* wait for children */43 if (ret == left_pid)44 printf("left child terminated, status: %x\n", status);45 else if (ret == right_pid)46 printf("right child terminated, status: %x\n", status);47 else48 printf("yow! unknown child %d terminated, status %x\n",49 ret, status);50 }5152 return 0;53 }Строки 22–25 создают канал. Это должно быть сделано в самом начале.
Строки 27–31 создают левого потомка, а строки 33–37 создают правого потомка. В обоих случаях родитель продолжает линейное исполнение ветви
main()execСтроки 39–40 закрывают родительскую копию канала.
Строки 42–50 в цикле ожидают потомков, пока
wait()55 /* left_child --- осуществляет работу левого потомка */5657 void left_child(void)58 {59 static char *left_argv[] = { "echo", "hi", "there", NULL };6061 close(pipefd[0]);62 close(1);63 dup(pipefd[1]);64 close(pipefd[1]);6566 execvp("echo", left_argv);67 _exit(errno == ENOENT ? 127 : 126);68 }6970 /* right_child --- осуществляет работу правого потомка */7172 void right_child(void)73 {74 static char *right_argv[] = { "sed", "s/hi/hello/g", NULL };7576 close(pipefd[1]);77 close(0);78 dup(pipefd[0]);79 close(pipefd[0]));8081 execvp("sed", right_argv);82 _exit(errno == ENOENT ? 127 : 126);83 }Строки 57–68 являются кодом для левого потомка. Процедура следует приведенным выше шагам, закрывая ненужный конец канала, закрывая первоначальный стандартный вывод, помещая с помощью
dup()execvp()_exit()execvp()Строки 72–83 делают подобные же шаги для правого потомка. Вот что происходит при запуске:
$ ch09-pipeline /* Запуск программы */left child terminated, status: 0 /* Левый потомок завершается до вывода (!) */hello there /* Вывод от правого потомка */right child terminated, status: 0$ ch09-pipeline /* Повторный запуск программы */hello there /* Вывод от правого потомка и ... */right child terminated, status: 0 /* Правый потомок завершается до левого */left child terminated, status: 0Обратите внимание, что порядок, в котором завершаются потомки, не является детерминированным. Он зависит от загрузки системы и многих других факторов, которые могут повлиять на планирование процессов. Вам следует проявить осторожность, чтобы избежать предположений о порядке действий при написании кода, создающего несколько процессов, в особенности для кода, который вызывает семейство функций
wait()Весь процесс показан на рис. 9.5.
Рис. 9.5. Создание конвейера родителем
На рис. 9.5 (а) изображена ситуация после создания родителем канала (строки 22–25) и двух порожденных процессов (строки 27–37).
На рис. 9.5 (b) показана ситуация после закрытия родителем канала (строки 39–40) и начала ожидания порожденных процессов (строки 42–50). Каждый порожденный процесс поместил канал на место стандартного вывода (левый потомок, строки 61–63) и стандартного ввода (строки 76–78).
Наконец, рис. 9.5 (с) изображает ситуацию после закрытия потомками первоначального канала (строки 64 и 79) и вызова
execvp()
9.4.2. Создание нелинейных конвейеров: /dev/fd/XX
/dev/fd/XXМногие современные системы Unix, включая GNU/Linux, поддерживают в каталоге
/dev/fd/dev/fd/0/dev/fd/1open()dup()Эти специальные файлы находят свое применение на уровне оболочки: Bash,
ksh88ksh93<(...)>(...)diffcommand1 > /tmp/out.$$.1command2 > /tmp/out.$$.2diff /tmp/out.$$.1 /tmp/out.$$.2rm /tmp/out.$$.1 /tmp/out.$$.2С замещением процессов это выглядит следующим образом:
diff <(command1) <(command2)Не надо никаких беспорядочных файлов для временного запоминания и удаления. Например, следующая команда показывает, что наш домашний каталог является ссылкой на другой каталог:
$ diff <(pwd) <(/bin/pwd)1c1< /home/arnold/work/prenhall/progex---> /d/home/arnold/work/prenhall/progexНезамысловатая команда
pwdcd/bin/pwdКак выглядит замещение процессов? Оболочка создает вспомогательные команды[99] ('
pwd/bin/pwddiff/dev/fd$ set -х /* Включить трассировку исполнения */$ diff <(pwd) <(/bin/pwd) /* Запустить команду */+ diff /dev/fd/63 /dev/fd/62 /* Трассировка оболочки: главная, программа, обратите внимание на аргументы */++ pwd /* Трассировка оболочки: вспомогательные программы */++ /bin/pwd1c1 /* Вывод diff */< /home/arnold/work/prenhall/progex---> /d/home/arnold/work/prenhall/progexЭто показано на рис. 9.6.
Рис. 9.6. Замещение процесса
Если на вашей системе есть
/dev/fd
9.4.3. Управление атрибутами файла: fcntl()
Системный вызов
fcntl()
(«управление файлом») предоставляет контроль над различными атрибутами либо самого дескриптора файла, либо лежащего в его основе открытого файла. Справочная страница GNU/Linux fcntl(2) описывает это таким способом:
#include /* POSIX */
#include
int fcntl (int fd, int cmd);
int fcntl(int fd, int cmd, long arg);
int fcntl(int fd, int cmd, struct flock *lock);
Другими словами, функция принимает по крайней мере два аргумента; в зависимости от второго аргумента, она может принимать и третий аргумент.
Последняя форма, в которой третий аргумент является указателем на
struct flock
, предназначена для блокировки файла. Блокировка файлов сама по себе представляет большую тему; мы отложим обсуждение до раздела 14.2 «Блокировка файлов».
9.4.3.1. Флаг close-on-exec
После вызова
fork()
и перед вызовом exec()
следует убедиться, что новая программа наследует лишь те открытые файлы, которые ей нужны. Вы не захотите, чтобы порожденный процесс мешался в открытых файлах родителя, если только это так не задумано. С другой стороны, если у родителя множество открытых файлов, это будет искусственно ограничивать число новых файлов, которые может открыть порожденный процесс. (См. сопроводительную врезку.)
Организационно такое поведение может представлять проблему. Часть вашей программы, порождающая новый процесс, не должна особенно нуждаться в других частях программы, манипулирующей открытыми файлами. И цикл наподобие следующего неприятный, поскольку может не быть открытых файлов:
int j;
for (j = getdtablesize(); j >= 3; j--) /* закрыть все, кроме 0, 1, 2 */
(void)close(j);
Решением является флаг close-on-exec (закрытие при исполнении exec). Он является атрибутом самого дескриптора файла, а не лежащего в его основе открытого файла. Когда этот флаг установлен, система автоматически закрывает файл, когда процесс осуществляет
exec
. Установив этот флаг сразу после открытия файла, вам не нужно беспокоиться о том, что какой-нибудь порожденный процесс случайно его унаследует. (Оболочка автоматически устанавливает этот флаг для всех дескрипторов файлов, которые она открывает, начиная с номера 3 и выше.)
Аргумент
cmd
имеет два значения, относящиеся к флагу close-on-exec:
F_GETFD
Получает флаги дескриптора файла. Возвращаемое значение является значением всех установленных флагов дескриптора или -1 при ошибке.
F_SETFD
Устанавливает флаги дескриптора файла в содержащееся в
arg
(третий аргумент) значение. Возвращаемое значение равно 0 при успехе или -1 при ошибке.
В настоящий момент определен лишь один «флаг дескриптора файла»:
FD_CLOEXEC
. Эта именованная константа является нововведением POSIX[100], а большая часть кода использует просто 1 или 0:
if (fcntl(fd, F_SETFD, 1) < 0) ...
/* установить close-on-exec, обработать ошибки */
if (fcntl(fd, F_GETFD) == 1) ...
/* бит close-on-exec уже установлен */
Однако, определение POSIX допускает дальнейшее расширение, поэтому правильный способ написания такого кода больше соответствует этим строкам:
int fd;
long fd_flags;
if ((fd_flags = fcntl(fd, F_GETFD)) < 0) /* Получить флаги */
/* обработать ошибки */
fd_flags |= FD_CLOEXEC; /* Add close-on-exec flag */
if (fcntl(fd, F_SETFD, fd_flags) < 0) /* Установить флаги */
/* обработать ошибки */
ЗАМЕЧАНИЕ. Флаг close-on-exec является собственностью дескриптора, а не лежащего в его основе файла. Поэтому новый дескриптор, возвращенный функциями
dup()
или dup2()
(или fcntl()
с F_DUPD
, которую мы намереваемся посмотреть), не наследует установки флага close-on-exec первоначального дескриптора. Если вам нужно установить его также и для нового дескриптора файла, вы должны не забыть сделать это сами. Такое поведение имеет смысл: если вы просто вызвали dup()
, копируя один конец канала в 0 или 1, вы не захотите, чтобы система закрыла его вместо вас, как только процесс осуществит exec!
История борьбы close-on-exec от gawk
В языке awk операторы ввода/вывода используют обозначение перенаправления, сходное с обозначением для оболочки. Это включает односторонние каналы к и от подпроцесса:
print "something brilliant" > "/some/file" /* Вывод в файл */
getline my_record < "/some/other/file" /* Ввод из файла */
print "more words of wisdom" | "a_reader process" /* Вывод в подпроцесс */
"a_write_process" | getline some_input /* Ввод из подпроцесса */
У интерпретатора
awk
есть дескрипторы открытых файлов для всех перенаправлений файлов, а для обозначений каналов, создающих подпроцессы, интерпретатор awk
создает канал, а затем осуществляет fork
и exec
оболочки для запуска команды, приведенной в строке.
Теперь на современных системах часть стартового кода библиотеки С времени исполнения (который запускается до вызова
main()
) нуждается для управления использованием разделяемых библиотек во временно открытых файлах. Это означает, что для новой программы после исполнения exec
должны быть по крайней мере один или два неиспользуемых дескриптора файла, иначе программа просто не будет работать
Однажды один пользователь сообщил, что когда в программе было максимальное количество открытых файлов, ни один процесс, для которого она пыталась использовать для конвейера
fork
и exec
, не мог успешно начаться!
Вы, возможно, можете догадаться, что произошло. Порожденная оболочка унаследовала дескрипторы открытых файлов, которые
gawk
сама использовала для своих перенаправлений. Мы модифицировали gawk
так, чтобы установить флаг close-on-exec для всех перенаправлений файлов и каналов, что и решило проблему.
9.4.3.2. Дублирование дескриптора файла
Когда аргумент
cmd
функции fcntl()
равен F_DUPFD
, ее поведение похоже, но не идентично поведению dup2()
. В этом случае arg
является дескриптором файла, представляющим наименьшее приемлемое значение для нового дескриптора файла:
int new_fd = fcntl(old_fd, F_DUPFD, 7);
/* Возвращаемое значение между 7 и максимумом или неудача */
int new_fd = dup2(old_fd, 7);
/* Возвращаемое значение 7 или неудача */
Вы можете имитировать поведение
dup()
, которая возвращает наименьший свободный дескриптор файла, использовав 'fcntl(old_fd, F_DUPED, 0)
'.
Если вы помните, что дескрипторы файлов являются просто индексами внутренней таблицы, работа этой функции должна быть ясна. Третий аргумент просто предоставляет индекс, с которого ядро должно начать поиск неиспользуемого дескриптора файла.
Использовать ли в собственном коде
fcntl()
с F_DUPED
или dup()
или dup2()
, в значительной степени является делом вкуса. Все три функции API являются частью POSIX и широко поддерживаются. У нас легкое пристрастие к dup()
и dup2()
, поскольку они более специфичны в своих действиях, поэтому являются самодокументирующимися. Но поскольку все они довольно просты, эта аргументация может вас не убедить.
9.4.3.3. Работа с флагами статуса файла и режимами доступа
В разделе 4.6.3 «Возвращаясь к
open()
» мы предоставили полный список флагов O_xx, которые принимает open()
. POSIX разбивает их по функциям, классифицируя в соответствии с табл. 9.4.
Таблица 9.4. Флаги O_xx для
open()
, creat()
и fcntl()
Категория
Функции
Флаги
Доступ к файлу
open()
, fcntl()
O_RDONLY
, O_RDWR
, O_WRONLY
Создание файла
open()
O_CREAT
, O_EXCL
, O_NOCTTY
, O_TRUNC
Статус файла
open()
, fcntl()
O_APPEND
, O_DSYNC
, O_NONBLOCK
, O_RSYNC
, O_SYNC
Помимо первоначальной установки различных флагов с помощью
open()
, вы можете использовать fcntl()
для получения текущих установок, а также их изменения. Это осуществляется с помощью значений cmd
F_GETFL
и F_SETFL
соответственно. Например, вы можете использовать эти команды для изменения установки неблокирующего флага, O_NONBLOCK
, подобным образом:
int fd_flags;
if ((fd_flags = fcntl(fd, F_GETFL)) < 0)
/* обработать ошибку */
if ((fd_flags & O_NONBLOCK) != 0) { /* Установлен неблокирующий флаг */
fd_flags &= ~O_NONBLOCK; /* Сбросить его */
if (fcntl(fd, F_SETFL, fd_flags) != 0) /* Дать ядру новое значение */
/* обработать ошибку */
}
Помимо самих режимов именованная константа
O_ACCMODE
является маской, которую вы можете использовать для выделения из возвращаемого значения режимов прав доступа.
fd_flags = fcntl(fd, F_GETFL);
switch (fd_flags & O_ACCESS) {
case O_RDONLY:
/* ...действия только для чтения... */
break;
case O_WRONLY:
/* ...действия только для записи... */
break;
case O_RDWR:
/* ...действия для чтения и записи... */
break;
}
POSIX требует, чтобы
O_RDONLY
, O_RDWR
и O_WRONLY
были побитово различными, таким образом, гарантируется, что код, подобный только что показанному, будет работать и является простым способом определения того, как был открыт произвольный дескриптор файла.
Используя
F_SETFL
вы можете также изменить эти режимы, хотя по-прежнему применяется проверка прав доступа. Согласно справочной странице GNU/Linux fcnlt(2) флаг O_APPEND
не может быть сброшен, если он использовался при открытии файла.
9.4.3.4. Неблокирующий ввод/вывод для каналов и FIFO
Ранее для описания способа работы каналов мы использовали сравнение с двумя людьми, моющими и вытирающими тарелки с использованием сушилки; когда сушилка заполняется, останавливается моющий, а когда она пустеет, останавливается вытирающий. Это блокирующее поведение: производитель или потребитель блокируются в вызове
write()
или read()
, ожидая либо освобождения канала, либо появления в нем данных.
В действительности человек, ожидающий опустения или заполнения сушилки, не должен просто неподвижно стоять.[101] Вместо этого незанятый супруг мог бы пойти и найти другую работу по кухне (такую, как подметание всех крошек за детьми на полу), пока сушилка снова не будет готова.
На языке Unix/POSIX эта концепция обозначается термином неблокирующий ввод/вывод, т.е. запрошенный ввод/вывод либо завершается, либо возвращает значение ошибки, указывающее на отсутствие данных (для читающего) или отсутствие места (для записывающего). Неблокирующий ввод/вывод применяется к каналам и FIFO, а не к обычным файлам на диске. Он может применяться также и к определенным устройствам, таким как терминалы, и к сетевым соединениям, обе эти темы выходят за рамки данной книги.
С функцией
open()
может использоваться флаг O_NONBLOCK
для указания неблокирующего ввода/вывода, он может быть установлен и сброшен с помощью fcntl()
. Для open()
и read()
неблокирующий ввод/вывод прост.
Открытие FIFO с установленным или сброшенным
O_NONBLOCK
демонстрирует следующее поведение:
open("/fifо/file", O_RDONLY, mode)
Блокируется до открытия FIFO для записи.
open("/fifo/file", O_RDONLY | O_NONBLOCK, mode)
Открывает файл, возвращаясь немедленно.
open("/fifo/file", O_WRONLY, mode)
Блокирует до открытия FIFO для чтения.
open("/fifo/file", O_WRONLY | O_NONBLOCK, mode)
Если FIFO был открыт для чтения, открывает FIFO и немедленно возвращается. В противном случае возвращает ошибку (возвращаемое значение -1 и
errno
установлен в ENXIO
).
Как описано для обычных каналов, вызов
read()
для FIFO, который больше не открыт для чтения, возвращает конец файла (возвращаемое значение 0). Флаг O_NONBLOCK
в данном случае неуместен. Для пустого канала или FIFO (все еще открытых для записи, но не содержащих данных) все становится интереснее:
read(fd, buf, count) и сброшенный O_NONBLOCK
Функция
read()
блокируется до тех пор, пока в канал или FIFO не поступят данные.
read(fd, buf, count) и установленный O_NONBLOCK
Функция
read()
немедленно возвращает -1 с установленным в errno EAGAIN
.
В заключение, поведение
write()
более сложно. Для обсуждения этого нам нужно сначала представить концепцию атомарной записи. Атомарная запись — это такая запись, при которой все данные записываются целиком, не чередуясь с данными от других записей. POSIX определяет в
константу PIPE_BUF
. Запись в канал или FIFO данных размером менее или равным PIPE_BUF
байтов либо успешно завершается, либо блокируется в соответствии с подробностями, которые мы скоро приведем. Минимальным значением для PIPE_BUF
является _POSIX_PIPE_BUF
, что равняется 512. Само значение PIPE_BUF
может быть больше; современные системы GLIBC определяют ее размер в 4096, но в любом случае следует использовать эту именованную константу и не ожидать, что PIPE_BUF
будет иметь то же значение на разных системах.
Во всех случаях для каналов и FIFO
write()
добавляет данные в конец канала. Это происходит от того факта, что у каналов нет файловых смещений: в них нельзя осуществлять поиск.
Также во всех случаях, как упоминалось, записи размером вплоть до
PIPE_BUF
являются атомарными: данные не перемежаются с данными от других записей. Данные записи размером более PIPE_BUF
байтов могут перемежаться с данными других записей в произвольных границах. Это последнее означает, что вы не можете ожидать, что каждая порция размером PIPE_BUF
большого набора данных будет записана атомарно. Установка O_NONBLOCK
не влияет на это правило.
Как и в случае с
read()
, когда O_NONBLOCK
не установлен, write()
блокируется до тех пор, пока все данные не будут записаны.
Наиболее все усложняется, когда установлен
O_NONBLOCK
. Канал или FIFO ведут себя следующим образом:
размер ≥ nbytes
размер < abytes
nbytes ≤ PIPE_BUF
write()
успешнаwrite()
возвращает (-1)/EAGAIN
размер > 0
размер = 0
nbytes > PIPE_BUF
write()
записывает, что можетwrite()
возвращает (-1)/EAGAIN
Для файлов, не являющихся каналами и FIFO и к которым может быть применен
O_NONBLOCK
, поведение следующее:
размер > 0
write()
записывает, что может
размер = 0
write()
возвращает -1/EAGAIN
Хотя есть ряд сбивающих с толку изменений поведения в зависимости от того, канал это или не канал, установлен
O_NONBLOCK
или сброшен, есть в канале место для записи или нет, а также в зависимости от размера предполагаемой записи, эти правила предназначены для упрощения программирования:
• Всегда можно отличить конец файла:
read()
возвращает 0 байтов.
• Если нет доступных для чтения данных,
read()
либо завершается успешно, либо возвращает указание «нет данных для чтения»: EAGAIN
, что означает «попытайтесь снова позже».
• Если для записи нет места,
write()
либо блокируется до успешного завершения (O_NONBLOCK
сброшен), либо завершается неудачей с ошибкой «в данный момент нет места для записи»: EAGAIN
.
• Когда место есть, будет записано столько данных, сколько возможно, так что в конечном счете все данные будут переписаны.
Подводя итог, если вы собираетесь использовать неблокирующий ввод/вывод, любой код, который использует
write()
, должен быть способен обработать укороченную запись, когда успешно записан меньший объем данных, чем было затребовано. Устойчивый код в любом случае должен быть написан таким способом: даже в случае обычного файла диск может оказаться заполненным и write()
сможет записать лишь часть данных.
Более того, вы должны быть готовы обработать
EAGAIN
, понимая, что в этом случае неудача write()
не обязательно означает фатальную ошибку. То же верно для кода, использующего для чтения неблокирующий ввод/вывод: признайте, что и здесь EAGAIN
не является фатальным. (Однако, может стоит подсчитывать число таких отказов, оставив попытки, когда их слишком много.)
Неблокирующий ввод/вывод действительно усложняет вашу жизнь, в этом нет никакого сомнения. Но для многих приложений он является необходимостью, позволяющей выполнить задание. Снова рассмотрите спулер печати. Демон спулера не может позволить себе находиться в блокирующем
read()
для файла FIFO, которому представлены входящие задания. Он должен иметь также возможность отслеживать запущенные задания и, возможно, периодически проверять состояние печатающих устройств (например, убедиться, что не заело бумагу).
9.4.3.5. Сводка fcntl()
Сводка для системного вызова
fcntl()
приведена в табл. 9.5.
Таблица 9.5. Сводка
fcntl()
Значение cmd
Значение arg
Возвращает
F_DUPFD
Наименьший новый дескриптор
Дублирует аргумент fd
F_GETFD
Получает флаги дескриптора файла (close-on-exec)
F_SETFD
Новое значение флага
Устанавливает флаги дескриптора файла (close-on-exec)
F_GETFL
Получает флаги основного файла
F_SETFL
Новое значение флага
Устанавливает флаги основного файла
Флаги создания, статуса и прав доступа файла копируются, когда дескриптор файла дублируется. Флаг close-on-exec не копируется.
fcntl()Системный вызов
fcntl()#include /* POSIX */ #include int fcntl (int fd, int cmd);int fcntl(int fd, int cmd, long arg);int fcntl(int fd, int cmd, struct flock *lock);Другими словами, функция принимает по крайней мере два аргумента; в зависимости от второго аргумента, она может принимать и третий аргумент.
Последняя форма, в которой третий аргумент является указателем на
struct flock9.4.3.1. Флаг close-on-exec
После вызова
fork()exec()Организационно такое поведение может представлять проблему. Часть вашей программы, порождающая новый процесс, не должна особенно нуждаться в других частях программы, манипулирующей открытыми файлами. И цикл наподобие следующего неприятный, поскольку может не быть открытых файлов:
int j;for (j = getdtablesize(); j >= 3; j--) /* закрыть все, кроме 0, 1, 2 */ (void)close(j);Решением является флаг close-on-exec (закрытие при исполнении exec). Он является атрибутом самого дескриптора файла, а не лежащего в его основе открытого файла. Когда этот флаг установлен, система автоматически закрывает файл, когда процесс осуществляет
execАргумент
cmdF_GETFDПолучает флаги дескриптора файла. Возвращаемое значение является значением всех установленных флагов дескриптора или -1 при ошибке.
F_SETFDУстанавливает флаги дескриптора файла в содержащееся в
argВ настоящий момент определен лишь один «флаг дескриптора файла»:
FD_CLOEXECif (fcntl(fd, F_SETFD, 1) < 0) ... /* установить close-on-exec, обработать ошибки */if (fcntl(fd, F_GETFD) == 1) ... /* бит close-on-exec уже установлен */Однако, определение POSIX допускает дальнейшее расширение, поэтому правильный способ написания такого кода больше соответствует этим строкам:
int fd;long fd_flags;if ((fd_flags = fcntl(fd, F_GETFD)) < 0) /* Получить флаги */ /* обработать ошибки */fd_flags |= FD_CLOEXEC; /* Add close-on-exec flag */if (fcntl(fd, F_SETFD, fd_flags) < 0) /* Установить флаги */ /* обработать ошибки */ЗАМЕЧАНИЕ. Флаг close-on-exec является собственностью дескриптора, а не лежащего в его основе файла. Поэтому новый дескриптор, возвращенный функциями
dup()dup2()fcntl()F_DUPDdup()gawkВ языке awk операторы ввода/вывода используют обозначение перенаправления, сходное с обозначением для оболочки. Это включает односторонние каналы к и от подпроцесса:
print "something brilliant" > "/some/file" /* Вывод в файл */getline my_record < "/some/other/file" /* Ввод из файла */print "more words of wisdom" | "a_reader process" /* Вывод в подпроцесс */"a_write_process" | getline some_input /* Ввод из подпроцесса */У интерпретатора
awkawkforkexecТеперь на современных системах часть стартового кода библиотеки С времени исполнения (который запускается до вызова
main()execОднажды один пользователь сообщил, что когда в программе было максимальное количество открытых файлов, ни один процесс, для которого она пыталась использовать для конвейера
forkexecВы, возможно, можете догадаться, что произошло. Порожденная оболочка унаследовала дескрипторы открытых файлов, которые
gawkgawk9.4.3.2. Дублирование дескриптора файла
Когда аргумент
cmdfcntl()F_DUPFDdup2()argint new_fd = fcntl(old_fd, F_DUPFD, 7); /* Возвращаемое значение между 7 и максимумом или неудача */int new_fd = dup2(old_fd, 7); /* Возвращаемое значение 7 или неудача */Вы можете имитировать поведение
dup()fcntl(old_fd, F_DUPED, 0)Если вы помните, что дескрипторы файлов являются просто индексами внутренней таблицы, работа этой функции должна быть ясна. Третий аргумент просто предоставляет индекс, с которого ядро должно начать поиск неиспользуемого дескриптора файла.
Использовать ли в собственном коде
fcntl()F_DUPEDdup()dup2()dup()dup2()9.4.3.3. Работа с флагами статуса файла и режимами доступа
В разделе 4.6.3 «Возвращаясь к
open()open()Таблица 9.4. Флаги O_xx для
open()creat()fcntl()| Категория | Функции | Флаги |
|---|---|---|
| Доступ к файлу | |
|
| Создание файла | |
|
| Статус файла | |
|
Помимо первоначальной установки различных флагов с помощью
open()fcntl()cmdF_GETFLF_SETFLO_NONBLOCKint fd_flags;if ((fd_flags = fcntl(fd, F_GETFL)) < 0) /* обработать ошибку */if ((fd_flags & O_NONBLOCK) != 0) { /* Установлен неблокирующий флаг */ fd_flags &= ~O_NONBLOCK; /* Сбросить его */ if (fcntl(fd, F_SETFL, fd_flags) != 0) /* Дать ядру новое значение */ /* обработать ошибку */}Помимо самих режимов именованная константа
O_ACCMODEfd_flags = fcntl(fd, F_GETFL);switch (fd_flags & O_ACCESS) {case O_RDONLY: /* ...действия только для чтения... */ break;case O_WRONLY: /* ...действия только для записи... */ break;case O_RDWR: /* ...действия для чтения и записи... */ break;}POSIX требует, чтобы
O_RDONLYO_RDWRO_WRONLYИспользуя
F_SETFLO_APPEND9.4.3.4. Неблокирующий ввод/вывод для каналов и FIFO
Ранее для описания способа работы каналов мы использовали сравнение с двумя людьми, моющими и вытирающими тарелки с использованием сушилки; когда сушилка заполняется, останавливается моющий, а когда она пустеет, останавливается вытирающий. Это блокирующее поведение: производитель или потребитель блокируются в вызове
write()read()В действительности человек, ожидающий опустения или заполнения сушилки, не должен просто неподвижно стоять.[101] Вместо этого незанятый супруг мог бы пойти и найти другую работу по кухне (такую, как подметание всех крошек за детьми на полу), пока сушилка снова не будет готова.
На языке Unix/POSIX эта концепция обозначается термином неблокирующий ввод/вывод, т.е. запрошенный ввод/вывод либо завершается, либо возвращает значение ошибки, указывающее на отсутствие данных (для читающего) или отсутствие места (для записывающего). Неблокирующий ввод/вывод применяется к каналам и FIFO, а не к обычным файлам на диске. Он может применяться также и к определенным устройствам, таким как терминалы, и к сетевым соединениям, обе эти темы выходят за рамки данной книги.
С функцией
open()O_NONBLOCKfcntl()open()read()Открытие FIFO с установленным или сброшенным
O_NONBLOCKopen("/fifо/file", O_RDONLY, mode)Блокируется до открытия FIFO для записи.
open("/fifo/file", O_RDONLY | O_NONBLOCK, mode)Открывает файл, возвращаясь немедленно.
open("/fifo/file", O_WRONLY, mode)Блокирует до открытия FIFO для чтения.
open("/fifo/file", O_WRONLY | O_NONBLOCK, mode)Если FIFO был открыт для чтения, открывает FIFO и немедленно возвращается. В противном случае возвращает ошибку (возвращаемое значение -1 и
errnoENXIOКак описано для обычных каналов, вызов
read()O_NONBLOCKread(fd, buf, count) и сброшенный O_NONBLOCKФункция
read()read(fd, buf, count) и установленный O_NONBLOCKФункция
read()errno EAGAINВ заключение, поведение
write()PIPE_BUFPIPE_BUFPIPE_BUF_POSIX_PIPE_BUFPIPE_BUFPIPE_BUFВо всех случаях для каналов и FIFO
write()Также во всех случаях, как упоминалось, записи размером вплоть до
PIPE_BUFPIPE_BUFPIPE_BUFO_NONBLOCKКак и в случае с
read()O_NONBLOCKwrite()Наиболее все усложняется, когда установлен
O_NONBLOCK| размер ≥ nbytes | размер < abytes | |
|---|---|---|
|
|
|
| размер > 0 | размер = 0 | |
|
|
|
Для файлов, не являющихся каналами и FIFO и к которым может быть применен
O_NONBLOCKразмер > 0
write()размер = 0
write()-1/EAGAINХотя есть ряд сбивающих с толку изменений поведения в зависимости от того, канал это или не канал, установлен
O_NONBLOCK• Всегда можно отличить конец файла:
read()• Если нет доступных для чтения данных,
read()EAGAIN• Если для записи нет места,
write()O_NONBLOCKEAGAIN• Когда место есть, будет записано столько данных, сколько возможно, так что в конечном счете все данные будут переписаны.
Подводя итог, если вы собираетесь использовать неблокирующий ввод/вывод, любой код, который использует
write()write()Более того, вы должны быть готовы обработать
EAGAINwrite()EAGAINНеблокирующий ввод/вывод действительно усложняет вашу жизнь, в этом нет никакого сомнения. Но для многих приложений он является необходимостью, позволяющей выполнить задание. Снова рассмотрите спулер печати. Демон спулера не может позволить себе находиться в блокирующем
read()9.4.3.5. Сводка fcntl()
Сводка для системного вызова
fcntl()Таблица 9.5. Сводка
fcntl()Значение |
Значение |
Возвращает |
|---|---|---|
|
Наименьший новый дескриптор | Дублирует аргумент |
|
Получает флаги дескриптора файла (close-on-exec) | |
|
Новое значение флага | Устанавливает флаги дескриптора файла (close-on-exec) |
|
Получает флаги основного файла | |
|
Новое значение флага | Устанавливает флаги основного файла |
Флаги создания, статуса и прав доступа файла копируются, когда дескриптор файла дублируется. Флаг close-on-exec не копируется.
9.5. Пример: двусторонние каналы в gawk
gawkДвусторонний канал соединяет два процесса двунаправленным образом. Обычно, по крайней мере для одного из процессов, на канал с другим процессом настраиваются как стандартный ввод, так и стандартный вывод. Оболочка Корна (
kshкоманды и аргументы движка базы данных |& /* Запустить сопроцесс в фоновом режиме */print -p "команда базы данных" /* Записать в сопроцесс */read -p db_response /* Прочесть из сопроцесса */Здесь движок базы данных представляет любую серверную программу, которая может управляться интерфейсной частью, в данном случае, сценарием
kshРис. 9.7. Сопроцессы оболочки Корна
В обычном
awkawkgawk|&kshawkprint "команда" |& "движок базы данных" /* Запустить сопроцесс, записать в него */"движок базы данных" |& getline db_response /* Прочесть из сопроцесса */gawk|&io.cgawktwo_way_open()1561 static int1562 two_way_open(const char *str, struct redirect *rp)1563 { ...1827 /* случай 3: двусторонний канал с порожденным процессом */1828 {1829 int ptoc[2], сtop[2];1830 int pid;1831 int save_errno;18351836 if (pipe(ptoc) < 0)1837 return FALSE; /* установлен errno, диагностика от вызывающего */18381839 if (pipe(ctop) < 0) {1840 save_errno = errno;1841 close(ptoc[0]);1842 close(ptoc[1]);1843 errno = save_errno;1844 return FALSE;1845 }Первым шагом является создание двух каналов,
ptocctopСтроки 1836–1837 создают первый канал,
ptocsave_errnoerrnopipe()close()errno1906 if ((pid = fork()) < 0) {1907 save_errno = errno;1908 close(ptoc[0]); close(ptoc[1]);1909 close(ctop[0]); close(ctop[1]);1910 errno = save_errno;1911 return FALSE;1912 }Строки 1906–1912 порождают процесс, на этот раз закрывая оба канала, если
fork()errno1914 if (pid == 0) { /* порожденный процесс */1915 if (close(1) == -1)1916 fatal(_("close of stdout in child failed (%s)"),1917 strerror(errno));1918 if (dup(ctop[1]) != 1)1919 fatal(_{"moving pipe to stdout in child failed (dup: %s)"), strerror(errno));1920 if (close(0) == -1)1921 fatal(_("close of stdin in child failed (%s)"),1922 strerror(errno));1923 if (dup(ptoc[0]) != 0)1924 fatal(_("moving pipe to stdin in child failed (dup: %s)"), strerror(errno));1925 if (close(ptoc[0]) == -1 || close(ptoc[1]) == -11926 || close(ctop[0]) == -1 || close(ctop[1]) == -1)1927 fatal(_("close of pipe failed (%s)"), strerror(errno));1928 /* stderr HE дублируется в stdout потомка */1929 execl("/bin/sh", "sh", "-c", str, NULL);1930 _exit(errno == ENOENT ? 127 : 126);1931 }Строки 1914–1931 обрабатывают код потомка, с соответствующей проверкой ошибок и сообщениями на каждом шагу. Строка 1915 закрывает стандартный вывод. Строка 1918 копирует записываемый конец канала от потомка к родителю на 1. Строка 1920 закрывает стандартный ввод, а строка 1923 копирует читаемый конец канала от родителя к потомку на 0. Если это все работает, стандартные ввод и вывод теперь на месте и подключены к родителю.
Строки 1925–1926 закрывают все четыре первоначальные дескрипторы файлов каналов, поскольку они больше не нужны. Строка 1928 напоминает нам, что стандартная ошибка остается на месте. Это лучшее решение, поскольку пользователь увидит ошибки от сопроцесса. Программа
awk2>&1Наконец, строки 1929–1930 пытаются запустить для оболочки
execl()1934 /* родитель */1935 rp->pid = pid;1936 rp->iop = iop_alloc(ctop[0], str, NULL);1937 if (rp->iop == NULL) {1938 (void)close(ctop[0]);1939 (void)close(ctop[1]);1940 (void)close(ptoc[0]);1941 (void)close(ptoc[1]);1942 (void)kill(pid, SIGKILL); /* overkill? (pardon pun) */19431944 return FALSE;1945 }Первым шагом родителя является настройка входного конца от сопроцесса. Указатель
rpstruct redirectFILE*IOBUF*iopIOBUFgawkСтрока 1935 сохраняет значение ID процесса. Строка 1936 выделяет память для новой
IOBUFNULLIOBUFЕсли выделение памяти потерпело неудачу, строки 1937–1942 производят очистку, закрывая каналы и посылая сигнал «kill» порожденным процессам, чтобы заставить их завершить работу. (Функция
kill()kill()killpg()1946 rp->fp = fdopen(ptoc[1], "w");1947 if (rp->fp == NULL) {1948 iop_close(rp->iop);1949 rp->iop = NULL;1950 (void)close(ctop[0]);1951 (void)close(ctop[1]);1952 (void)close(ptoc[0]);1953 (void)close(ptoc[1]);1954 (void)kill(pid, SIGKILL); /* избыточно? (пардон, каламбур)*/19551956 return FALSE;1957 }Строки 1946–1957 аналогичны. Они устанавливают вывод родителя на потомка, сохраняя дескриптор файла для записывающего конца канала от родителя к потомку в
FILE*fdopen()С этого момента записываемый конец канала от родителя к потомку и читаемый конец канала от потомка к родителю хранятся в более крупных структурах:
FILE*IOBUF1960 os_close_on_exec(ctop[0], str, "pipe", "from");1961 os_close_on_exec(ptoc[1], str, "pipe", "from");19621963 (void)close(ptoc[0]);1964 (void)close(ctop[1]);19661967 return TRUE;1968 } ...1977 }Строки 1960–1961 устанавливают флаг close-on-exec для двух дескрипторов, которые остались открытыми.
os_close_on_exec()#ifdefio.cНаконец, строки 1963–1964 закрывают концы каналов, которые не нужны родителю, а строка 1967 возвращает TRUE для обозначения успеха.
9.6. Рекомендуемая литература
Управление заданиями сложно, включает группы процессов, сеансы, механизмы ожидания, сигналы и манипулирование группой процессов терминала. По существу, мы решили не вдаваться в детали. Однако, вы можете захотеть взглянуть на следующие книги:
1. Advanced Programming in the UNIX Environment, 2nd edition, by W. Richard Stevens and Stephen Rago. Addison-Wesley, Reading Massachusetts, USA, 2004. ISBN: 0-201-43307-9.
Эта книга и полна, и основательна, охватывая элементарное и продвинутое программирование под Unix. Она превосходно освещает группы процессов, сеансы, управление заданиями и сигналы
2. The Design and Implementation of the 4.4 BSD Operating System, by Marshall Kirk McKusick, Keith Bostic, Michael J. Karels, and John S. Quarterman. Addison-Wesley, Reading, Massachusetts, USA, 1996. ISBN: 0-201-54979-4.
Эта книга дает хороший обзор того же материала, включая обсуждение структур данных ядра, которое можно найти в разделе 4.8 этой книги.
9.7. Резюме
• Новые процессы создаются с помощью
fork()• Унаследованные разделяемые дескрипторы файлов делают возможным многое из высокоуровневой семантики Unix и элегантные управляющие структуры оболочки. Это одна из наиболее фундаментальных частей оригинального дизайна Unix. Из-за разделения дескрипторов файл на самом деле не закрывается до тех пор, пока не будет закрыт последний открытый дескриптор файла. Это в особенности касается каналов, но затрагивает также освобождение дисковых блоков для удаленных, но все еще открытых файлов.
• Вызовы
getpid()getppid()init• Системный вызов
nice()• Системный вызов
exec()• Значение
argv[0]fork()exec• Функция
atexit()exit()_exit()_Exit()exit()FILE*atexit()execmain()exit()main()exit(0)•
wait()waitpid()waitpid()• Системы GNU/Linux и большинство Unix-систем поддерживают также функции BSD
wait3()wait4()union waitstruct rusagewaitpid()• Группы процессов являются частью более крупного механизма управления заданиями, который включает сигналы, сеансы и манипулирование состоянием терминала,
getpgrp()getpgid()setpgrp()setpgid()exec• Каналы и FIFO предоставляют односторонний коммуникационный канал между двумя процессами. Каналы должны быть установлены общим предком, тогда как FIFO могут использоваться любыми двумя процессами. Каналы создаются с помощью
pipe()mkfifo()•
dup()dup2()close()/dev/fd•
fcntl()fcntl()• Дублирования дескриптора файла, имитирования
dup()dup2()• Получения и установки флага close-on-exec. Флаг close-on-exec является в настоящее время единственным атрибутом дескриптора файла, но он важен. Он не копируется в результате действия
dup()• Получение и установка флагов, управляющих нижележащим файлом. Из них
O_NONBLOCKУпражнения
1. Напишите программу, которая выводит как можно больше сведений о текущем процессе: PID, PPID, открытые файлы, текущий каталог, значение относительного приоритета и т.д. Как вы можете сказать, какие файлы открыты? Если несколько дескрипторов файлов ссылаются на один и тот же файл, укажите это. (Опять-таки, как вы можете это узнать?)
2. Как вы думаете,
atexit()atexit()exit()exit()3. Программа
xargs$ grep ARG_MAX /usr/include/*.h /usr/include/*/*.h /* Командная строка */bash: /bin/grep: Argument list too long /* Сообщение оболочки об ошибке */$ find /usr/include -name '*.h' | xargs grep ARG_MAX /* find b xargs работают *//usr/include/sys/param.h:#define NCARGS ARG_MAX...Константа
ARG_MAXНапишите простую версию
xargs4. Компоновка значения status, заполняемого функциями
wait()waitpid()Рис. 9.8. Компоновка значения status функции
wait()• Ненулевое значение в битах 0–7 указывает на завершение по сигналу.
• Все единичные биты в поле сигнала указывает, что порожденный процесс остановлен. В этом случае биты 9-15 содержат номер сигнала.
• Единичное значение бита 8 указывает завершение со снимком процесса.
• Если биты 0–7 равны нулю, процесс завершился нормально. В этом случае биты 9–15 являются статусом завершения.
Напишите с данными сведениями макросы POSIX
WIFEXITED()5. Помня, что
dup2()dup2()close()fcntl()fcntl()6. Есть ли на вашей системе каталог
/dev/fd7. Напишите новую версию
ch09-pipeline.c8. (Трудное) Как вы можете узнать, вызывал ли ваш процесс когда-нибудь
chroot()9. Есть ли на вашей системе каталог
/proc
Глава 10
Сигналы
Данная глава освещает все подробности сигналов, важную, но сложную часть GNU/Linux API.
10.1. Введение
Сигнал является указанием, что случилось какое-то событие, например, попытка сослаться на адрес памяти, который не является частью адресного пространства вашей программы, или когда пользователь нажимает CTRL-C для выхода из программы (называется генерированием прерывания).
Программа может узнать лишь, что определенный сигнал был по крайней мере однажды. Обычно вы не можете сказать, случился ли один и тот же сигнал несколько раз. Вы можете отличить один сигнал от другого и управлять способом реагирования программы на различные сигналы.
Механизмы обработки сигналов развились с течением времени. Как бывает почти со всеми такими механизмами, стандартизованы и доступны как первоначальные, так и более новые API. Однако, из фундаментальных API обработка сигналов обнаруживает, возможно, самые широкие изменения; имеется множество возможностей обработки, чтобы преуспеть в использовании наиболее подходящего API. В результате, возможно, это самая трудная глава в книге. Мы сделаем всевозможное, чтобы сделать изложение более ясным, но если вы проработаете эту главу более тщательно, чем обычно, это поможет.
В отличие от большинства глав в данной книге, наше представление здесь историческое, связанное с освещением развития API, включая API, которые никогда не следует использовать в новом коде. Мы делаем это, потому что это упрощает изложение, делая понятным, почему функция POSIX API
sigaction()
поддерживает все те возможности, которые поддерживает.
10.2. Действия сигналов
Каждый сигнал (вскоре мы представим полный список) имеет связанное с ним действие по умолчанию. POSIX обозначает это как диспозицию (disposition) сигнала. Это то действие, которое ядро осуществляет для процесса, когда поступает определенный сигнал. Действие по умолчанию варьирует:
Завершение
Процесс завершается.
Игнорирование
Сигнал игнорируется. Программа никогда не узнает, что что-то случилось.
Снимок образа процесса
Процесс завершается, и ядро создает файл core (в текущем каталоге процесса), содержащий образ работавшей на момент поступления сигнала программы. Снимок процесса может впоследствии использоваться с отладчиком для исследования состояния программы (см. главу 15 «Отладка»).
По умолчанию системы GNU/Linux создают файлы с именем
core.pid
, где pid
является ID завершаемого процесса. (Это можно изменить; см. sysctl(8).) Такое именование позволяет хранить в одном и том же каталоге несколько файлов core
, за счет использования большего дискового пространства.[105] Традиционные системы Unix называют файл core
, и это ваше дело сохранить какие-нибудь файлы core
для последующего изучения, если есть шанс создания других таких же файлов в том же каталоге.
Остановка
Процесс останавливается. Впоследствии он может быть возобновлен. (Если вы использовали управление заданиями оболочки с помощью CTRL-Z,
fg
и bg
, вы понимаете остановку процесса.)
10.3. Стандартные сигналы С: signal()
и raise()
Стандарт ISO С определяет первоначальный API управления сигналами V7 и новый API для посылки сигналов. Вы должны использовать их для программ, которым придется работать на не-POSIX системах, или в случаях, когда предоставляемые ISO С API возможности являются достаточными.
10.3.1. Функция signal()
Действие сигнала изменяется с помощью функции
signal()
. Вы можете изменить действие на «игнорировать сигнал», «восстановить для сигнала действие системы по умолчанию» или «вызвать при появлении сигнала мою функцию с номером сигнала в качестве параметра».
Функция, которую вы предоставляете для распоряжения сигналом, называется обработчиком сигнала (или просто обработчиком), а установка ее в соответствующем месте осуществляет перехват (catch) сигнала.
Получив эти сведения, давайте перейдем к API. В заголовочном файле
представлены определения макросов для поддерживаемых сигналов и объявления функций управления сигналами, предоставляемыми стандартом С:
#include /* ISO С */
void (*signal(int signum, void (*func)(int)))(int);
Это объявление для функции signal() почти невозможно прочесть. Поэтому справочная страница GNU/Linux signal(2) определяет ее таким способом:
typedef void (*sighandler_t)(int);
sighandler_t signal(int signum, sighandler_t handler);
Теперь это более вразумительно. Тип
sighandler_t
является указателем на функцию с возвращаемым типом void
, которая принимает один целый аргумент. Это целое является номером поступающего сигнала.
Функция
signal()
принимает номер сигнала в качестве своего первого параметра, а указатель функции (новый обработчик) в качестве своего второго аргумента. Если последний не является указателем функции, он может быть лишь SIG_DEF,
что означает «восстановить действие по умолчанию», либо SIG_IGN
, что означает «игнорировать сигнал».
signal()
изменяет действие для signum
и возвращает предыдущее действие. (Это дает вам возможность восстановить при желании предыдущее действие.) Возвращаемое значение может равняться также SIG_ERR
, что указывает на произошедшую ошибку. (Некоторые сигналы невозможно перехватить или игнорировать; предоставление для них обработчика сигнала или неверный signum
создают эту ошибку.) В табл. 10.1 перечислены сигналы, доступные под GNU/Linux, их числовые значения, действия по умолчанию для каждого, формальный стандарт или современная операционная система, которые их определяют, и смысл каждого.
Таблица 10.1. Сигналы GNU/Linux
Имя
Значение
По умолчанию
Источник
Смысл
SIGHUP
1
Term
POSIX
Отсоединение
SIGINT
2
Term
ISO C
Прерывание
SIGQUIT
3
Core
POSIX
Выход
SIGILL
4
Core
ISO C
Недействительная инструкция
SIGTRAP
5
Core
POSIX
Трассировочная ловушка
SIGABRT
6
Core
ISO C
Прекращение
SIGIOT
6
Core
BSD
Ловушка IOT
SIGBUS
7
Core
BSD
Ошибка шины
SIGFPE
8
Core
ISO C
Исключение с плавающей точкой
SIGKILL
9
Term
POSIX
Завершение, неблокируемый
SIGUSR1
10
Term
POSIX
Сигнал 1 пользователя
SIGSEGV
11
Core
ISO C
Нарушение сегмента
SIGUSR2
12
Term
POSIX
Сигнал 2 пользователя
SIGPIPE
13
Term
POSIX
Нарушенный канал
SIGALRM
14
Term
POSIX
Аварийные часы
SIGTERM
15
Term
ISO C
Завершение
SIGSTKFLT
16
Term
Linux
Ошибка стека в процессоре (не используется)
SIGCHLD
17
Ignr
POSIX
Изменение статуса порожденного процесса
SIGCLD
17
Ignr
System V
То же, что и SIGCHLD (для совместимости)
SIGCONT
18
POSIX
Продолжить при остановке
SIGSTOP
19
Stop
POSIX
Стоп, неблокируемый
SIGTSTP
20
Stop
POSIX
Стоп от клавиатуры
SIGTTIN
21
Slop
POSIX
Фоновое чтение от tty
SIGTTOU
22
Stop
POSIX
Фоновая запись в tty
SIGURG
23
Ignr
BSD
Срочный сигнал сокета
SIGXCPU
24
Core
BSD
Превышение предела процессора
SIGXFSZ
25
Core
BSD
Превышение предела размера файла
SIGVTALRM
26
Term
BSD
Виртуальные аварийные часы
SIGPROF
27
Term
BSD
Профилирующие аварийные часы
SIGWINCH
28
Ignr
BSD
Изменение размера окна
SIGIO
29
Term
BSD
Возможен ввод/вывод
SIGPOLL
29
Term
System V
Опрашиваемое событие, то же, что и SIGIO (для совместимости)
SIGPWR
30
Term
System V
Повторный запуск из-за сбоя питания
SIGSYS
31
Core
POSIX
Неверный системный вызов
Обозначения: Core: Завершить процесс и создать снимок образа процесса Ignr: Игнорировать сигнал Stop: Остановить процесс. Term: Завершить процесс.
Более старые версии оболочки Борна (
/bin/sh
) непосредственно связывали с номерами сигналов ловушки (traps), которые являются обработчиками сигналов на уровне оболочки. Таким образом, всесторонне образованному Unix-программисту нужно было знать не только имена сигналов для использования в коде С, но также и соответствующие номера сигналов! POSIX требует, чтобы команда trap
понимала символические имена сигналов (без префикса 'SIG
'), поэтому этого больше не требуется. Однако (главным образом для лучшего разбирательства), мы предоставили эти номера в интересах полноты из-за того, что однажды вам может понадобиться иметь дело со сценарием оболочки, созданным до POSIX, или с древним кодом на С, которые непосредственно используют номера сигналов.
ЗАМЕЧАНИЕ. Для некоторых более новых сигналов, от 16 и выше, соответствующие номера сигнала и их имена на различных платформах не обязательно совпадают! Проверьте заголовочные файлы и справочные страницы на своей системе. Табл. 10.1 верна для GNU/Linux
Некоторые системы определяют также и другие сигналы, такие, как
SIGEMT
, SIGLOST
и SIGINFO
. Справочная страница GNU/Linux signal(7) предоставляет полный список; если ваша программа должна обработать сигналы, не поддерживаемые GNU/Linux, это можно сделать с помощью #ifdef
:
#ifdef SIGLOST
/* ...обработать здесь SIGLOST... */
#endif
За исключением
SIGSTKFLT
, сигналы, перечисленные в табл. 10.1, широкодоступны и не нуждаются в заключении в #ifdef
.
Сигналы
SIGKILL
и SIGSTOP
нельзя перехватить или игнорировать (или блокировать, как описано далее в главе). Они всегда выполняют действие по умолчанию, указанное в табл. 10.1.
Чтобы увидеть список поддерживаемых сигналов, вы можете использовать '
kill -l
'. На одной из наших систем GNU/Linux:
$ kill -l
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL
5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE
9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2
13) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD
18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN
22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO
30) SIGPWR 31) SIGSYS 32) SIGRTMIN 33) SIGRTMIN+1
34) SIGRTMIN+2 35) SIGRTMIN+3 36) SIGRTMIN+4 37) SIGRTMIN+5
38) SIGRTMIN+6 39) SIGRTMIN+7 40) SIGRTMIN+8 41) SIGRTMIN+9
42) SIGRTMIN+10 43) SIGRTMIN+11 44) SIGRTMIN+12 45) SIGRTMIN+13
46) SIGRTMIN+14 47) SIGRTMIN+15 48) SIGRTMAX-15 49) SIGRTMAX-14
50) SIGRTMAX-13 51) SIGRTMAX-12 52) SIGRTMAX-11 53) SIGRTMAX-10
54) SIGRTMAX-9 55) SIGRTMAX-8 56) SIGRTMAX-7 57) SIGRTMAX-6
58) SIGRTMAX-5 59) SIGRTMAX-4 60) SIGRTMAX-3 61) SIGRTMAX-2
62) SIGRTMAX-1 63) SIGRTMAX
Сигналы
SIGRTXXX
являются сигналами реального времени, сложная тема, которую мы не будем рассматривать.
10.3.2. Программная отправка сигналов: raise()
Помимо внешнего генерирования, сигнал может быть отправлен непосредственно самой программой с использованием стандартной функции С
raise()
:
#include /* ISO С */
int raise(int sig);
Эта функция посылает сигнал
sig
вызывающему процессу. (Это действие имеет свое применение; вскоре мы увидим пример.)
Поскольку
raise()
определена стандартом С, для процесса это наиболее переносимый способ отправить себе сигнал. Есть другие способы, которые мы обсудим далее в главе.
10.4. Обработчики сигналов в действии
Множество осложнений и отклонений обнаруживается после установки на место обработчика, после его вызова и впоследствии возвращения.
10.4.1. Традиционные системы
После помещения на место обработчика сигнала ваша программа развивается своим путем. Интересные вещи возникают лишь с появлением сигнала (например, пользователь нажал CTRL-C для прерывания вашей программы, или был сделан вызов
raise()
).
По получении сигнала ядро останавливает процесс, где бы он ни был. Затем оно имитирует вызов процедуры обработчика сигнала, передавая ему номер сигнала в качестве ее единственного аргумента. Ядро устраивает все таким образом, что нормальный возврат из функции обработчика сигнала (либо посредством
return
, либо в результате выпадения из конца функции) передает управление в ту точку программы, в которой она находилась в момент появления сигнала.
Что происходит после обработки сигнала, когда тот же самый сигнал появится в следующий раз снова? Остается ли обработчик на том же месте? Или же он сбрасывается, и для сигнала используется действие по умолчанию? Ответ, по историческим причинам, «зависит от». В частности, стандарт С оставляет это на усмотрение реализации.
На практике V7 и традиционные системы System V, такие, как Solaris, устанавливают для сигнала действие по умолчанию.
Давайте рассмотрим простой обработчик сигнала в действии под Solaris. Следующая программа,
ch10-catchint.c
, перехватывает SIGINT
. Обычно вы генерируете этот сигнал, набирая на клавиатуре CTRL-C.
1 /* ch10-catchint.c - перехват SIGINT, по крайней мере, однажды. */
2
3 #include
4 #include
5 #include
6
7 /* handler --- простой обработчик сигнала. */
8
9 void handler(int signum)
10 {
11 char buf[200], *cp;
12 int offset;
13
14 /* Пройти через это испытание , чтобы избежать fprintf(). */
15 strcpy(buf, "handler: caught signal ");
16 cp = buf + strlen(buf); /* cp указывает на завершающий '\0' */
17 if (signum > 100) /* маловероятно */
18 offset = 3;
19 else if (signum > 10)
20 offset = 2;
21 else
22 offset = 1;
23 cp += offset;
24
25 *cp-- = '\0'; /* завершить строку */
26 while (signum >0) { /* work backwards, filling in digits */
27 *cp-- = (signum % 10) + '0';
28 signum /= 10;
29 }
30 strcat(buf, "\n");
31 (void)write(2, buf, strlen(buf));
32 }
33
34 /* main --- установить обработку сигнала и войти в бесконечный цикл */
35
36 int main(void)
37 {
38 (void)signal(SIGINT, handler);
39
40 for(;;)
41 pause(); /* ждать сигнал, см. далее в главе */
42
43 return 0;
44 }
Строки 9–22 определяют функцию обработки сигнала (остроумно названную
handler()
[106]). Все, что эта функция делает, — выводит номер перехваченного сигнала и возвращается. Для вывода этого сообщения она выполняет множество ручной работы, поскольку fprintf()
не является «безопасной» для вызова из обработчика сигнала. (Вскоре это будет описано в разделе 10.4.6 «Дополнительные предостережения».)
Функция
main()
устанавливает обработчик сигнала (строка 38), а затем входит в бесконечный цикл (строки 40–41). Вот что происходит при запуске:
$ ssh solaris.example.com
/* Зарегистрироваться на доступной системе Solaris */
Last login: Fri Sep 19 04:33:25 2003 from 4.3.2.1.
Sun Microsystems Inc. SunOS 5.9 Generic May 2002
$ gcc ch10-catchint.c /* Откомпилировать программу */
$ a.out /* Запустить ее */
^C handler: caught signal 2 /* Набрать ^C, вызывается обработчик */
^C /* Попробовать снова, но на этот раз... */
$ /* Программа завершается */
Поскольку V7 и другие традиционные системы восстанавливают действие сигнала по умолчанию, поэтому когда вы хотите снова получить сигнал в будущем, функция обработчика должна немедленно переустановить саму себя:
void handler(int signum) {
char buf[200], *cp;
int offset;
(void)signal(signum, handler); /* переустановить обработчик */
/* ...оставшаяся часть функции как прежде... */
}
10.4.2. BSD и GNU/Linux
BSD 4.2 изменила способ работы
signal()
.[107] На системах BSD обработчик сигнала после его возвращения остается на месте. Системы GNU/Linux следуют поведению BSD. Вот что происходит под GNU/Linux:
$ ch10-catchint /* Запустить программу */
handler: caught signal 2 /* Набираем ^C, вызывается обработчик */
handler: caught signal 2 /* И снова... */
handler: caught signal 2 /* И снова! */
handler: caught signal 2 /* Помогите! */
handler: caught signal 2 /* Как нам это остановить?! */
Quit (core dumped) /* ^\, генерирует SIGQUIT. Bay */
На системе BSD или GNU/Linux обработчик сигнала не должен дополнительно использовать '
signal(signum, handler)
' для переустановки обработчика. Однако, лишний вызов не причиняет никакого вреда, поэтому сохраняется статус-кво.
В действительности, POSIX предоставляет функцию
bsd_signal()
, которая идентична signal()
за тем исключением, что она гарантирует, что обработчик сигнала останется установленным:
#include /* XSI, устаревает */
void (*bsd_signal(int sig, void (*func)(int)))(int);
Это устраняет проблемы переносимости. Если вы знаете, что ваша программа будет работать лишь на системах POSIX, вы можете воспользоваться
bsd_signal()
вместо signal()
.
Одно предостережение — эта функция также помечена как «устаревающая», что означает возможность отказа от нее в будущем стандарте. На практике, даже если от нее откажутся, поставщики скорее всего долгое время будут ее поддерживать. (Как мы увидим, функция API POSIX
sigaction()
предоставляет достаточно возможностей для написания рабочей версии, если это вам нужно.)
10.4.3. Игнорирование сигналов
Более практично, когда вызывается обработчик сигнала, это означает, что программа должна завершиться и выйти. Было бы раздражающим, если бы большинство программ по получении
SIGINT
выводили бы сообщение и продолжали работу; смысл сигнала в том, что они должны остановиться!
Например, рассмотрите программу
sort
. sort
, возможно, создала любое число временных файлов для использования на промежуточных этапах процесса сортировки. По получении SIGINT
, sort
должна удалить временные файлы и выйти. Вот упрощенная версия обработчика сигнала из GNU Coreutils sort.c
:
/* Обработка прерываний и отсоединений. Упрощена для представления */
static void sighandler(int sig) {
signal(sig, SIG_IGN); /* Отныне этот сигнал игнорировать */
cleanup(); /* Очистка после себя */
signal(sig, SIG_DFL); /* Восстановление действия по умолчанию */
raise(sig); /* Повторно отправить сигнал */
}
Установка действия
SIG_IGN
гарантирует, что все последующие появляющиеся сигналы SIGINT
не повлияют на продолжающийся процесс очистки. Когда функция cleanup()
завершит работу, восстановление действия SIG_DFL
позволяет системе сделать снимок образа процесса, если это нужно возникшему сигналу. Вызов raise()
восстанавливает сигнал. Затем восстановленный сигнал вызывает действие по умолчанию, которое, скорее всего, завершит программу. (Далее в этой главе мы полностью покажем обработчик сигнала sort.c
.)
10.4.4. Системные вызовы, допускающие повторный запуск
Значение
EINTR
для errno
(см. раздел 4.3 «Определение ошибок») указывает, что системный вызов был прерван. Хотя с этим значением ошибки может завершаться большое количество системных вызовов, двумя наиболее значительными являются read()
и write()
. Рассмотрите следующий код:
void handler(int signal) { /* обработка сигналов */ }
int main(int argc, char **argv) {
signal(SIGINT, handler);
...
while ((count = read(fd, buf, sizeof buf)) > 0) {
/* Обработка буфера */
}
if (count == 0)
/* конец файла, очистка и т.п. */
else if (count == -1)
/* ошибка */
...
}
Предположим, что система успешно прочла (и заполнила) часть буфера, когда возник
SIGINT
. Системный вызов read()
еще не вернулся из ядра в программу, но ядро решает, что оно может доставить сигнал. Вызывается handler()
, запускается и возвращается в середину read()
. Что возвратит read()
?
В былые времена (V7, более ранние системы System V)
read()
возвратила бы -1 и установила бы errno
равным EINTR
. Не было способа сообщить, что данные были переданы. В данном случае V7 и System V действуют, как если бы ничего не случилось: не было перемещений данных в и из буфера пользователя, и смещение файла не было изменено. BSD 4.2 изменила это. Были два случая:
Медленные устройства
«Медленное устройство» является в сущности терминалом или почти всяким другим устройством, кроме обычного файла. В этом случае
read()
могла завершиться с ошибкой EINTR
, лишь если не было передано никаких данных, когда появился сигнал. В противном случае системный вызов был бы запущен повторно, и read()
возвратилась бы нормально.
Обычные файлы
Системный вызов был бы запущен повторно В этом случае
read()
вернулась бы нормально; возвращенное значение могло быть либо числом запрошенных байтов, либо числом действительно прочитанных байтов (как в случае чтения вблизи конца файла).
Поведение BSD несомненно полезно; вы всегда можете сказать, сколько данных было прочитано.
Поведение POSIX сходно, но не идентично первоначальному поведению BSD. POSIX указывает, что
read()
[108] завершается с ошибкой EINTR
лишь в случае появления сигнала до начала перемещения данных. Хотя POSIX ничего не говорит о «медленных устройствах», на практике это условие проявляется именно на них.
В противном случае, если сигнал прерывает частично выполненную
read()
, возвращенное значение является числом уже прочитанных байтов. По этой причине (а также для возможности обработки коротких файлов) всегда следует проверять возвращаемое read()
значение и никогда не предполагать, что прочитано все запрошенное количество байтов. (Функция POSIX API sigaction()
, описанная позже, позволяет при желании получить поведение повторно вызываемых системных вызовов BSD.)
10.4.4.1. Пример: GNU Coreutils safe_read()
и safe_write()
Для обработки случая EINTR в традиционных системах GNU Coreutils использует две функции,
safe_read()
и safe_write()
. Код несколько запутан из-за того, что один и тот же файл за счет включения #include и макросов реализует обе функции. Из файла lib/safe-read.c
в дистрибутиве Coreutils:
1 /* Интерфейс read и write для .повторных запусков после прерываний.
2 Copyright (С) 1993, 1994, 1998, 2002 Free Software Foundation, Inc.
/* ... куча шаблонного материала опущена... */
56
57 #ifdef SAFE_WRITE
58 # include "safe-write.h"
59 # define safe_rw safe_write /* Создание safe_write() */
60 # define rw write /* Использование системного вызова write() */
61 #else
62 # include "safe-read.h"
63 # define safe_rw safe_read /* Создание safe_read() */
64 # define rw read /* Использование системного вызова read() */
65 # undef const
66 # define const /* пусто */
67 #endif
68
69 /* Прочесть (записать) вплоть до COUNT байтов в BUF из(в) дескриптора FD, повторно запуская вызов при
70 прерывании. Вернуть число действительно прочитанных (записанных) байтов, 0 для EOF
71 или в случае ошибки SAFE_READ_ERROR(SAFE_WRITE_ERROR). */
72 size_t
73 safe_rw(int fd, void const *buf, size_t count)
74 {
75 ssize_t result;
76
77 /* POSIX ограничивает COUNT значением SSIZE_MAX, но мы еще больше ограничиваем его, требуя,
78 чтобы COUNT <= INT_MAX, для избежания ошибки в Tru64 5.1.
79 При уменьшении COUNT сохраняйте указатель файла выровненным по размеру блока.
80 Обратите внимание, что read (write) может быть успешным в любом случае, даже если прочитано (записано)
81 менее COUNT байтов, поэтому вызывающий должен быть готов обработать
82 частичные результаты. */
83 if (count > INT_MAX)
84 count = INT_MAX & -8191;
85
86 do
87 {
88 result = rw(fd, buf, count);
89 }
90 while (result < 0 && IS_EINTR(errno));
91
92 return (size_t) result;
93 }
Строки 57–67 обрабатывают определения, создавая соответствующим образом
safe_read()
и safe_write()
(см. ниже safe_write.c
).
Строки 77–84 указывают на разновидность осложнений, возникающих при чтении. Здесь один особый вариант Unix не может обработать значения, превышающие
INT_MAX
, поэтому строки 83–84 выполняют сразу две операции: уменьшают значение числа, чтобы оно не превышало INT_MAX
, и сохраняют его кратным 8192. Последняя операция служит эффективности дисковых операций: выполнение ввода/вывода с кратным основному размеру дискового блока объемом данных более эффективно, чем со случайными размерами данных. Как отмечено в комментарии, код сохраняет семантику read()
и write()
, где возвращенное число байтов может быть меньше затребованного.
Обратите внимание, что параметр
count
может и в самом деле быть больше INT_MAX
, поскольку count представляет тип size_t
, который является беззнаковым (unsigned). INT_MAX
является чистым int
, который на всех современных системах является знаковым.
Строки 86–90 представляют действительный цикл, повторно осуществляющий операцию, пока она завершается ошибкой
EINTR
. Макрос IS_EINTR()
не показан, но он обрабатывает случай в системах, на которых EINTR
не определен. (Должен быть по крайней мере один такой случай, иначе код не будет возиться с установкой макроса; возможно, это было сделано для эмуляции Unix или POSIX в не-Unix системе.) Вот safe_write.c
:
1 /* Интерфейс write для повторного запуска после прерываний.
2 Copyright (С) 2002 Free Software Foundation, Inc.
/* ...куча шаблонного материала опущена... */
17
18 #define SAFE_WRITE
19 #include "safe-read.с"
В строке 18
#define
определяет SAFE_WRITE
; это связано со строками 57–60 в safe_read.с
.
10.4.4.2. Только GLIBC: TEMP_FAILURE_RETRY()
Файл GLIBC определяет макрос TEMP_FAILURE_RETRY(), который вы можете использовать для инкапсулирования любого системного вызова, который может при неудачном вызове установить errno в EINTR. Его «объявление» следующее:
#include /* GLIBC */
long int TEMP_FAILURE_RETRY(expression);
Вот определение макроса:
/* Оценить EXPRESSION и повторять, пока оно возвращает -1 с 'errno',
установленным в EINTR. */
# define TEMP_FAILURE_RETRY(expression) \
(__extension__ \
({ long int __result; \
do __result = (long int)(expression); \
while (__result == -1L && errno == EINTR); \
__result; }))
Макрос использует расширение GCC к языку С (как обозначено ключевым словом
__extension__
), которое допускает заключенным в фигурные скобки внутри обычных скобок выражениям возвращать значение, действуя таким образом подобно простому выражению.
Используя этот макрос, мы могли бы переписать
safe_read()
следующим образом:
size_t safe_read(int fd, void const *buf, size_t count) {
ssize_t result;
/* Ограничить count, как в ранее приведенном комментарии. */
if (count > INT_MAX)
count = INT_MAX & ~8191;
result = TEMP_FAILURE_RETRY(read(fd, buf, count));
return (size_t)result;
}
10.4.5. Состояния гонок и sig_atomic_t
(ISO C)
Пока обработка одного сигнала за раз выглядит просто: установка обработчика сигнала в
main()
и (не обязательная) переустановка самого себя обработчиком сигнала (или установка действия SIG_IGN
) в качестве первого действия обработчика.
Но что произойдет, если возникнут два идентичных сигнала, один за другим? В частности, что, если ваша система восстановит действие по умолчанию для вашего сигнала, а второй сигнал появится после вызова обработчика, но до того, как он себя восстановит?
Или предположим, что вы используете
bsd_signal()
, так что обработчик остается установленным, но второй сигнал отличается от первого? Обычно обработчику первого сигнала нужно завершить свою работу до того, как запускается второй, а каждый обработчик сигнала не должен временно игнорировать все прочие возможные сигналы!
Оба случая относятся к состоянию гонки. Одним решением для этих проблем является как можно большее упрощение обработчиков сигналов. Это можно сделать, создав флаговые переменные, указывающие на появление сигнала. Обработчик сигнала устанавливает переменную в true и возвращается. Затем основная логика проверяет флаговую переменную в стратегических местах:
int sig_int_flag = 0; /* обработчик сигнала устанавливает в true */
void int_handler(int signum) {
sig_int_flag = 1;
}
int main(int argc, char **argv) {
bsd_signal(SIGINT, int_handler);
/* ...программа продолжается... */
if (sig_int_flag) {
/* возник SIGINT, обработать его */
}
/* ...оставшаяся логика... */
}
(Обратите внимание, что эта стратегия уменьшает окно уязвимости, но не устраняет его).
Стандарт С вводит специальный тип —
sig_atomic_t
— для использования с такими флаговыми переменными. Идея, скрывающаяся за этим именем, в том, что присвоение значений переменным этого типа является атомарной операцией: т.е. они совершаются как одно делимое действие. Например, на большинстве машин присвоение значения int
осуществляется атомарно, тогда как инициализация значений в структуре осуществляется либо путем копирования всех байтов в (сгенерированном компилятором) цикле, либо с помощью инструкции «блочного копирования», которая может быть прервана. Поскольку присвоение значения sig_atomic_t
является атомарным, раз начавшись, оно завершается до того, как может появиться другой сигнал и прервать его.
Наличие особого типа является лишь частью истории. Переменные
sig_atomic_t
должны быть также объявлены как volatile
:
volatile sig_atomic_t sig_int_flag = 0; /* обработчик сигнала устанавливает в true */
/* ...оставшаяся часть кода как раньше... */
Ключевое слово
volatile
сообщает компилятору, что переменная может быть изменена извне, за спиной компилятора, так сказать. Это не позволяет компилятору применить оптимизацию, которая могла бы в противном случае повлиять на правильность кода
Структурирование приложения исключительно вокруг переменных
sig_atomic_t
ненадежно. Правильный способ обращения с сигналами показан далее, в разделе 10.7 «Сигналы для межпроцессного взаимодействия».
10.4.6. Дополнительные предостережения
Стандарт POSIX предусматривает для обработчиков сигналов несколько предостережений:
• Что случается, когда возвращаются обработчики для
SIGFPE
, SIGILL
, SIGSEGV
или любых других сигналов, представляющих «вычислительные исключения», не определено.
• Если обработчик был вызван в результате вызова
abort()
, raise()
или kill()
, он не может вызвать raise()
. abort()
описана в разделе 12.4 «Совершение самоубийства: abort()
», a kill()
описана далее в этой главе. (Описанная далее функция API sigaction()
с обработчиком сигнала, принимающая три аргумента, дает возможность сообщить об этом, если это имеет место.)
• Обработчики сигналов могут вызвать лишь функции из табл. 10.2. В частности, они должны избегать функций
. Проблема в том, что во время работы функции
может возникнуть прерывание, когда внутреннее состояние библиотечной функции находится в середине процесса обновления. Дальнейшие вызовы функций
могут повредить это внутреннее состояние.
Список в табл. 10.2 происходит из раздела 2.4 тома System Interfaces (Системные интерфейсы) стандарта POSIX 2001. Многие из этих функций относятся к сложному API и больше не рассматриваются в данной книге.
Таблица 10.2. Функции, которые могут быть вызваны из обработчика сигнала
_Exit()
fpathconf()
raise()
sigqueue()
_exit()
fstat()
read()
sigset()
accept()
fsync()
readlink()
sigsuspend()
access()
ftruncate()
recv()
sleep()
aio_error()
getegid()
recvfrom()
socket()
aio_return()
geteuid()
recvmsg()
socketpair()
aio_suspend()
getgid()
rename()
stat()
alarm()
getgroups()
rmdir()
sysmlink()
bind()
getpeername()
select()
sysconf()
cfgetispeed()
getpgrp()
sem_post()
tcdrain()
cfgetospeed()
getpid()
send()
tcflow()
cfsetispeed()
getppid()
sendmsg()
tcflush()
cfsetospeed()
getsockname()
sendto()
tcgetattr()
chdir()
getsockopt()
setgid()
tcgetpgrp()
chmod()
getuid()
setpgid()
tcsendbreak()
chown()
kill()
setsid()
tcsetattr()
clock_gettime()
link()
setsockopt()
tcsetpgrp()
close()
listen()
setuid()
time()
connect()
lseek()
shutdown()
timer_getoverrun()
creat()
lstat()
sigaction()
timer_gettime()
dup()
mkdir()
sigaddset()
timer_settime()
dup2()
mkfifo()
sigdelset()
times()
execle()
open()
sigemptyset()
umask()
execve()
pathconf()
sigfillset()
uname()
fchmod()
pause()
sigismember()
unlink()
fchown()
pipe()
signal()
utime()
fcntl()
poll()
sigpause()
wait()
fdatasync()
posix_trace_event()
sigpending()
waitpid()
fork()
pselect()
sigprocmask()
write()
10.4.7. Наша история до настоящего времени, эпизод 1
Сигналы являются сложной темой, и она становится еще более сбивающей с толку. Поэтому давайте на время сделаем остановку, сделаем шаг назад и подведем итог обсужденному до сих пор:
• Сигналы являются указанием того, что произошло некоторое внешнее событие.
•
raise()
является функцией ISO С для отправки сигнала текущему процессу. Как отправлять сигналы другим процессам, нам еще предстоит описать.
•
signal()
контролирует диспозицию сигнала, т.е. реакцию процесса на сигнал, когда он появляется. Сигнал можно оставить системе для обработки по умолчанию, проигнорировать или перехватить.
• Когда сигнал перехватывается, вызывается функция-обработчик. Вот где сложность начинает поднимать свою безобразную голову:
• ISO С не определяет, восстанавливается ли диспозиция сигнала по умолчанию до вызова обработчика или она остается на месте. Первое является поведением V7 и современных систем System V, таких, как Solaris. Последнее является поведением BSD, используемым также в GNU/Linux. (Для форсирования поведения BSD может использоваться функция POSIX
bsd_signal()
.)
• То, что случается при прерывании сигналом системного вызова, также различается в традиционной и BSD линейках. Традиционные системы возвращают -1 с errno, установленным в
EINTR
. BSD системы повторно запускают системный вызов после возвращения из обработчика. Макрос GLIBC TEMP_FAILURE_RETRY()
может помочь вам написать код для обработки системных вызовов, возвращающих -1 с errno
, установленным в EINTR
.
POSIX требует, чтобы частично выполненный системный вызов возвращал успешное завершение, указав, сколько работы было выполнено. Системный вызов, который еще не начал выполняться, вызывается повторно.
• Механизм
signal()
предоставляет плодотворную почву для появления условий гонки. В этой ситуации помогает тип данных ISO С sig_atomic_t
, но он не решает проблему, и определенный таким способом механизм не может обезопасить от проявления условий гонки.
• Применяется ряд дополнительных предостережений, и в частности, из обработчика сигнала безопасно может вызываться лишь часть стандартных библиотечных функций.
Несмотря на эти проблемы интерфейса
signal()
для простых программ достаточно, и он все еще широко используется.
10.5. API сигналов System V Release 3: sigset()
и др.
BSD 4.0 (примерно с 1980 г.) ввел дополнительные функции API для предоставления «надежных» сигналов.[109] В частности, стало возможным блокировать сигналы. Другими словами, программа могла сообщить ядру: «Зависни на этих конкретных сигналах в течении следующего небольшого промежутка времени, затем доставь их мне, когда я буду готов их принять». Большим преимуществом является то, что эта особенность упрощает обработчики сигналов, которые автоматически запускаются со своим заблокированным сигналом (чтобы избежать проблемы одновременной обработки двух сигналов) и, возможно, также и с другими заблокированными сигналами.
System V Release 3 (примерно с 1984 г.) приняла эти API и популяризовала их, в большинстве связанных с Unix документации и книгах вы, возможно, увидите, что на эти API ссылаются, как ведущие начало от System V Release 3. Эти функции следующие:
#include /* XSI */
int sighold(int sig); /* Добавить sig к маске сигналов процесса */
int sigrelse(int sig); /* Удалить sig из маски сигналов процесса */
int sigignore(int sig); /* Сокращение для sigset(sig, SIG_IGN) */
int sigpause(int sig);
/* Приостановить процесс, позволить появиться sig */
void (*sigset(int sig, void (*disp)(int)))(int);
/* sighandler_t sigset(int sig, sighandler_t disp); */
Стандарт POSIX для этих функций описывает их поведение в терминах маски сигналов процесса. Маска сигналов процесса отслеживает, какие сигналы (если они вообще есть) процесс заблокировал в настоящее время. Более подробно это описывается в разделе 10.6.2 «Наборы сигналов:
sigset_t
и связанные функции». В API System V Release 3 нет способа получить или изменить маску сигналов процесса в целом. Функции работают следующим образом:
int sighold(int sig)
Добавляет
sig
к списку заблокированных процессов (маска сигналов процесса).
int sigrelse(int sig)
Удаляет
sig
из маски сигналов процесса.
int sigignore(int sig)
Игнорирует
sig
. Это вспомогательная функция.
int sigpause(int sig)
Удаляет
sig
из маски сигналов процесса, а затем приостанавливает процесс до появления сигнала (см. раздел 10.7 «Сигналы для межпроцессного взаимодействия»).
sighandler_t sigset(int sig, sighandler_t disp)
Это замена для signal(). (Здесь мы использовали обозначение из справочной страницы GNU/Linux, чтобы упростить восприятие объявления функции.)
Для
sigset()
аргумент handler
может быть SIG_DFL
, SIG_IGN
или указатель функции, как и для signal()
. Однако, он может равняться также и SIG_HOLD
. В этом случае sig
добавляется к маске сигналов процесса, но связанное с ним действие никак не изменяется. (Другими словами, если бы у него был обработчик, он остается тем же; если было действие по умолчанию, оно не изменяется.)
Когда для установки обработчика сигнала используется
sigset()
и появляется сигнал, ядро сначала добавляет сигнал к маске процессов сигнала, блокируя любой дальнейший прием этого сигнала. Запускается обработчик, а когда он возвращается, ядро восстанавливает маску сигналов процесса в то состояние, какое было до запуска обработчика. (В модели POSIX если обработчик сигнала изменяет маску сигнала, это изменение переписывается в процессе восстановления предыдущей маски, когда обработчик возвращается.)
sighold()
и sigrelse()
могут использоваться совместно для выделения так называемых критических секций кода: участков кода, который не должен прерываться определенным сигналом, чтобы структуры данных не повреждались кодом обработчика сигнала.
ЗАМЕЧАНИЕ. POSIX стандартизует эти API, поскольку главной целью POSIX является формализация существующей практики, где это возможно. Однако, функции
sigaction()
, которые вскоре будут описаны, дают вам все, что делают эти API, и даже больше. В новых программах вам не следует использовать эти API Вместо этого используйте sigaction()
. (Мы заметили, что в справочной системе GNU/Linux нет даже страницы для sigset(2)!)
10.6. Сигналы POSIX
API POSIX основан на API
sigvec()
из BSD 4.2 и 4.3. С небольшими изменениями этот API можно было отнести к возможностям API как V7, так и System V Release 3. POSIX сделал эти изменения и переименовал API sigaction()
. Поскольку интерфейс sigvec()
широко не использовался, мы не будем его описывать. Вместо этого в данном разделе описывается только sigaction()
, который вы и должны так или иначе использовать. (На самом деле руководства BSD 4.4 от 1994 г. помечают sigvec()
как устаревшую, указывая читателю на sigaction()
.)
10.6.1. Обнажение проблемы
Что неладно с API System V Release 3? В конце концов, они предоставляют блокирование сигналов, так, что сигналы не теряются, и любой данный сигнал может быть надежно обработан.
Ответ в том, что этот API работает лишь с одним сигналом в одно и то же время. Программы обычно обрабатывают больше одного сигнала. И когда вы находитесь в середине процесса обработки одного сигнала, вы не хотите беспокоиться по поводу обработки еще и второго. (Предположим, вы только что начали отвечать по офисному телефону, когда зазвонил ваш мобильный телефон: вы бы предпочли, чтобы телефонная система ответила вызывающему, что в данный момент вы находитесь на другой линии и что скоро освободитесь, вместо того, чтобы проделывать все это самому.)
С API
sigset()
каждый обработчик сигнала должен был бы временно блокировать все другие сигналы, сделать свою работу, а затем разблокировать их. Проблема в том, что в промежутке между любыми двумя вызовами sighold()
может появиться еще не заблокированный сигнал. Сценарий, еще раз, распространенный, создающий условия гонки.
Решением является обеспечение возможности автоматической работы с группами сигналов, т.е. с помощью одного системного вызова. Вы достигаете этого, работая с наборами сигналов и маской сигналов процесса.
10.6.2. Наборы сигналов: sigset_t
и связанные функции
Маска сигналов процесса является списком сигналов, которые процесс в настоящее время заблокировал. Сила POSIX API в том, что маской сигналов процесса можно манипулировать атомарно, как единым целым.
Маска сигналов процесса программно представляется с помощью набора сигналов. Это тип
sigset_t
. Концептуально он представляет собой просто битовую маску, причем значения 0 и 1 представляют отсутствие или наличие определенного сигнала в маске.
/* Непосредственное манипулирование маской сигналов. НЕ ДЕЛАЙТЕ ЭТОГО! */
int mask = (1 << SIGHUP) | (1 << SIGINT);
/* битовая маска для SIGHUP и SIGINT */
Однако, поскольку в системе может быть больше сигналов, чем может содержаться в одной
int
или long
и поскольку интенсивное использование побитовых операций тяжело для восприятия, для управления наборами сигналов существует несколько функций API.
#include /* POSIX */
int sigemptyset(sigset_t *set);
int sigfillset(sigset_t *set);
int sigaddset(sigset_t *set, int signum);
int sigdelset(sigset_t *set, int signum);
int sigismember(const sigset_t *set, int signum);
Эти функции следующие:
int sigemptyset(sigset_t *set)
Освобождает набор сигналов. По возвращении
*set
не содержит сигналов. Возвращает 0 в случае успеха и -1 при ошибке.
int sigfillset(sigset_t *set)
Полностью заполняет набор сигналов. По возвращении
*set
содержит все сигналы, определенные системой. Возвращает 0 в случае успеха и -1 при ошибке.
int sigaddset(sigset_t *set, int signum)
Добавляет
signum
к маске сигналов процесса в *set
. Возвращает 0 в случае успеха и -1 при ошибке.
int sigdelset(sigset_t *set, int signum)
Удаляет
signum
из маски сигналов процесса в *set
. Возвращает 0 в случае успеха и -1 при ошибке.
int sigismember(const sigset_t *set, int signum)
Возвращает true/false, если
signum
присутствует или не присутствует в *set
.
Перед выполнением с переменной
sigset_t
каких-то действий всегда следует вызывать одну из функций sigemptyset()
или sigfillset()
. Существуют оба интерфейса, поскольку иногда бывает нужно начать с пустого набора и работать потом лишь с одним или двумя сигналами, а в другое время бывает нужно работать со всеми сигналами, возможно, убирая один или два сигнала.
10.6.3. Управление маской сигналов: sigprocmask()
и др.
Маска сигналов процесса вначале пуста - заблокированных сигналов нет. (Это упрощение; см. раздел 10.9 «Сигналы, передающиеся через
fork()
и exec()
.) Три функции позволяют работать непосредственно с маской сигналов процесса:
#include /* POSIX */
int sigprocmask(int how, const sigset_t *set, sigset_t *oldset);
int sigpending(sigset_t *set);
int sigsuspend(const sigset_t *set);
Функции следующие:
int sigprocmask(int how, const sigset_t *set, sigset_t *oldset)
Если
oldset
не равен NULL
, получается маска сигналов текущего процесса и помещается в *oldset
. Затем маска сигналов процесса обновляется в соответствии с содержимым set
и значением how
, который должен иметь одно из следующих значений:
SIG_BLOCK
Объединить сигналы в *set
с маской сигналов текущего процесса. Новая маска является объединением текущей маски и *set
.
SIG_UNBLOCK
Удалить сигналы в *set
из маски сигналов процесса. Это не представляет проблемы, если *set
содержит сигнал, который не содержится в текущей маске сигналов процесса.
SIG_SETMASK
Заменить маску сигналов процесса содержимым *set
.
Если
set
равен NULL
, a oldset
— нет, значение how
неважно. Эта комбинация получает маску сигналов текущего процесса, не меняя ее. (Это явно выражено в стандарте POSIX, но не ясно из справочной страницы GNU/Linux.)
int sigpending(sigset_t *set)
Эта функция позволяет увидеть, какие сигналы ожидают решения; т.е.
*set
заполнен этими сигналами, которые были посланы, но они еще не доставлены, поскольку заблокированы.
int sigsuspend(const sigset_t *set)
Эта функция временно заменяет маску сигналов процесса содержимым
*set
, а затем приостанавливает процесс, пока сигнал не будет получен. По определению, заставить функцию вернуться может только сигнал, не находящийся в *set
(см. раздел 10.7 «Сигналы для межпроцессного взаимодействия).
10.6.4. Перехват сигналов: sigaction()
Наконец мы готовы взглянуть на функцию
sigaction()
. Эта функция сложна, и мы намеренно опускаем множество деталей, которые предназначены для специального использования. Стандарт POSIX и справочная страница sigaction(2) предоставляют все подробности, хотя вы должны тщательно прочесть и то, и другое, чтобы полностью все усвоить.
#include /* POSIX */
int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);
Аргументы следующие:
int signum
Интересующий сигнал, как в случае с другими функциями обработки сигналов.
const struct sigaction *act
Определение нового обработчика для сигнала
signum
.
struct sigaction *oldact
Определение текущего обработчика. Если не
NULL
, система до установки *act
заполняет *oldact
. *act
может быть NULL
, в этом случае *oldact
заполняется, но больше ничего не меняется.
Таким образом,
sigaction()
и устанавливает новый обработчик, и получает старый за одно действие. struct sigaction
выглядит следующим образом.
/* ПРИМЕЧАНИЕ: Порядок в структуре может варьировать. Могут быть
также и другие поля! */
struct sigaction {
sigset_t sa_mask; /* Дополнительные сигналы для блокирования */
int sa_flags; /* Контролирует поведение */
void (*sa_handler)(int);
/* Может образовать объединение с sa_sigaction */
void (*sa_sigaction)(int, siginfo_t*, void*);
/* Может образовать объединение с sa_handler */
}
Поля следующие:
sigset_t sa_mask
Набор дополнительных сигналов для блокирования при запуске функции обработчика. Таким образом, когда вызывается обработчик, общий набор заблокированных сигналов является объединением сигналов в маске процесса, сигналов в
act->mask
и, если SA_NODEFER
сброшен, signum
.
int sa_flags
Флаги, контролирующие обработку сигнала ядром. См. обсуждение далее.
void (*sa_handler)(int)
Указатель на «традиционную» функцию обработчика. У нее такой же прототип (возвращаемый тип и список параметров), как у функции обработчика для
signal()
, bsd_signal()
и sigset()
.
void (*sa_sigaction)(int, siginfo_t*, void*)
Указатель на функцию обработчика «нового стиля». Функция принимает три аргумента, которые вскоре будут описаны.
Которая из функций
act->sa_handler
и act->sa_sigaction
используется, зависит от флага SA_SIGINFO
в act->sa_flags
. Когда имеется, используется act->sa_sigaction
; в противном случае используется act->sa_handler
. Как POSIX, так и справочная страница GNU/Linux указывают, что эти два поля могут перекрываться в памяти (т. е. быть частью union
). Таким образом, никогда не следует использовать оба поля в одной и той же struct sigaction
.
Поле
sa_flags
составляется с помощью побитового ИЛИ значений одного или более флагов, перечисленных в табл. 10.3.
Таблица 10.3. Значения флагов для
sa_flags
Флаг
Значение
SA_NOCLDSTOP
Этот флаг имеет смысл лишь для SIGCHLD
. Когда он установлен, родитель не получает сигнал при остановке порожденною процесса сигналами SIGSTOP
, SIGTSTP
, SIGTTIN
или SIGTTOU
. Эти сигналы обсуждаются позже, в разделе 10.8.2
SA_NOCLDWAIТ
Этот флаг имеет смысл лишь для SIGCHLD
. Его поведение сложно. Мы отложим объяснение на потом, см. раздел 10.8.3
SA_NODEFER
Обычно данный сигнал блокируется, когда вызывается обработчик сигнала. Когда установлен один из этих флагов, данный сигнал не блокируется при запуске обработчика SA_NODEFER
является официальным именем POSIX данного флага (которое и следует использовать)
SA_NOMASK
Альтернативное имя для SA_NODEFER
[110]
SA_SIGINFO
Обработчик сигнала принимает три аргумента. Как упоминалось, при данном установленном флаге должно использоваться поле sa_sigaction
вместо sa_handler
.
SA_ONSTACK
Это продвинутая возможность. Обработчики сигналов могут вызываться с использованием предоставленной пользователем памяти в качестве «альтернативного стека сигнала». Эта память даётся ядру для подобного использования посредством sigaltstack()
(см. sigaltstack(2)). Эта особенность больше не описывается в данной книге
SA_RESETHAND
Этот флаг обеспечивает поведение V7: после вызова обработчика восстанавливается действие сигнала по умолчанию. Официальным именем POSIX флага (которое следует использовать) является SA_RESETHAND
SA_ONESHOT
Альтернативное имя для SA_RESETHAND.
SA_RESTART
Этот флаг предоставляет семантику BSD: системные вызовы, которые могут завершиться с ошибкой EINTR
и которые получают этот сигнал, запускаются повторно.
Когда в
act->sa_flags
установлен флаг SA_SIGINFO
, поле act->sa_sigaction
является указателем на функцию, объявленную следующим образом:
void action_handler(int sig, siginfo_t *info, void *context) {
/* Здесь тело обработчика */
}
Структура
siginfo
_t предоставляет изобилие сведений о сигнале:
/* Определение POSIX 2001. Действительное содержание может на разных системах быть разным. */
typedef struct {
int si_signo; /* номер сигнала */
int si_errno; /* значение при ошибке */
int si_code; /* код сигнала; см. текст */
pid_t si_pid; /* ID процесса, пославшего сигнал */
uid_t si_uid; /* настоящий UID посылающего процесса */
void *si_addr; /* адрес вызвавшей ошибку инструкции */
int si_status; /* значение завершения, может включать death-by-signal */
long si_band; /* связывающее событие для SIGPOLL/SIGIO */
union sigval si_value; /* значение сигнала (расширенное) */
} siginfo_t;
Поля
si_signo
, si_code
и si_value
доступны для всех сигналов. Другие поля могут быть членами объединения, поэтому должны использоваться лишь для тех сигналов, для которых они определены. В структуре siginfo_t
могут быть также и другие поля.
Почти все поля предназначены для расширенного использования. Все подробности содержатся в стандарте POSIX и справочной странице sigaction(2). Однако, мы можем описать простое использование поля
si_code
.
Для
SIGBUS
, SIGCHLD
, SIGFPE
, SIGILL
, SIGPOLL
, SIGSEGV
и SIGTRAP
поле si_code может принимать любое из набора предопределенных значений, специфичных для каждого сигнала, указывая на причину появления сигнала. Откровенно говоря, детали несколько чрезмерны; повседневному коду на самом деле нет необходимости иметь с ними дела (хотя позже мы рассмотрим значения для SIGCHLD
). Для всех остальных сигналов член si_code
имеет одно из значений из табл. 10.4.
Таблица 10.4. Значения происхождения сигнала для
si_code
Значение
Только GLIBC
Смысл
SI_ASYNCIO
Асинхронный ввод/вывод завершен (расширенный).
SI_KERNEL
√
Сигнал послан ядром.
SI_MESGQ
Состояние очереди сообщений изменилось (расширенный.)
SI_QUEUE
Сигнал послан из sigqueue()
(расширенный).
SI_SIGIO
√
SIGIO
поставлен в очередь (расширенный).
SI_TIMER
Время таймера истекло
SI_USER
Сигнал послан функцией kill()
. raise()
и abort()
также могут его вызвать, но это не обязательно.
В особенности полезно значение
SI_USER
; оно позволяет обработчику сигнала сообщить, был ли сигнал послан функциями raise()
или kill()
(описываются далее). Вы можете использовать эту информацию, чтобы избежать повторного вызова raise()
или kill()
.
Третий аргумент обработчика сигнала с тремя аргументами,
void *contex
t, является расширенной возможностью, которая больше не обсуждается в данной книге.
Наконец, чтобы увидеть
sigaction()
в действии, исследуйте полный исходный код обработчика сигнала для sort.c
:
2074 static void
2075 sighandler(int sig)
2076 {
2077 #ifndef SA_NOCLDSTOP /* В системе старого стиля... */
2078 signal(sig, SIG_IGN); /* - для игнорирования sig используйте signal()*/
2079 #endif - /* В противном случае sig автоматически блокируется */
2080
2081 cleanup(); /* Запуск кода очистки */
2082
2083 #ifdef SA_NOCLDSTOP /* В системе в стиле POSIX... */
2084 {
2085 struct sigaction sigact;
2086
2087 sigact.sa_handler = SIG_DFL; /* - Установить действие по умолчанию */
2088 sigemptyset(&sigact.sa_mask); /* - Нет дополнительных сигналов для блокирования */
2089 sigact.sa_flags = 0; /* - Специальные действия не предпринимаются */
2090 sigaction(sig, &sigact, NULL); /* - Поместить на место */
2091 }
2092 #else /* На системе в старом стиле... */
2093 signal(sig, SIG_DFL); /* - Установить действие по умолчанию */
2094 #endif
2095
2096 raise(sig); /* Повторно послать сигнал */
2097 }
Вот код в
main()
, который помещает обработчик на свое место:
2214 #ifdef SA_NOCLDSTOP /* На системе POSIX... */
2215 {
2216 unsigned i;
2217 sigemptyset(&caught_signals);
2218 for (i = 0; i < nsigs; i++) /* - Блокировать все сигналы */
2219 sigaddset(&caught_signals, sigs[i]);
2220 newact.sa_handler = sighandler; /* - Функция обработки сигнала */
2221 newact.sa_mask = caught_signals; /* - Установить для обработчика маску сигналов процесса */
2222 newact.sa_flags =0; /* - Особых флагов нет */
2223 }
2224 #endif
2225
2226 {
2227 unsigned i;
2228 for (i = 0; i < nsigs; i++) /* Для всех сигналов... */
2229 {
2230 int sig = sigs[i];
2231 #ifdef SA_NOCLDSTOP
2232 sigaction(sig, NULL, &oldact); /* - Получить старый обработчик */
2233 if (oldact.sa_handler != SIG_IGN) /* - Если этот сигнал не игнорируется */
2234 sigaction(sig, &newact, NULL); /* - Установить наш обработчик */
2235 #else
2236 if (signal(sig, SIG_IGN) != SIG_IGN)
2237 signal(sig, sighandler); /* - Та же логика со старым API */
2238 #endif
2239 }
2240 }
Мы заметили, что строки 2216–2219 и 2221 могут быть замещены одним вызовом:
sigfillset(&newact.sa_mask)
;
Мы не знаем, почему код написан именно таким способом.
Интерес представляют также строки 2233–2234 и 2236–2237, которые показывают правильный способ проверки того, игнорируется ли сигнал, и для установки обработчика лишь в том случае, если сигнал не игнорируется.
ЗАМЕЧАНИЕ. Функции API
sigaction()
и signal()
не должны использоваться вместе для одного и того же сигнала. Хотя POSIX идет на большие длинноты, чтобы сначала сделать возможным использование signal()
, получить struct sigaction
, представляющую диспозицию signal()
, и восстановить ее, все равно это плохая мысль. Код будет гораздо проще читать, писать и понимать, если вы используете одну функцию или другую взаимоисключающим образам
10.6.5. Извлечение ожидающих сигналов: sigpending()
Описанный ранее системный вызов
sigpending()
позволяет получить набор ожидающих сигналов, т.е тех сигналов, которые появились, но еще не доставлены из-за блокировки:
#include /* POSIX */
int sigpending(sigset_t *set);
Помимо разблокировки ожидающих сигналов, чтобы они могли быть доставлены, вы можете решить их игнорировать. Установка действия сигнала
SIG_IGN
вызывает сбрасывание сигнала (даже если он был заблокирован). Сходным образом для тех сигналов, действием по умолчанию для которых является их игнорирование, установка действия в SIG_DFL
также вызывает сбрасывание таких ожидающих сигналов.
10.6.6. Создание возможности для прерывания функций: siginterrupt()
Чтобы сделать определенную функцию прерываемой или повторно запускаемой в зависимости от значения второго аргумента, в качестве удобного средства может использоваться функция
siginterrupt()
. Объявление следующее:
#include /* XSI */
int siginterrupt(int sig, int flag);
В соответствии со стандартом POSIX поведение
siginterrupt()
эквивалентно следующему коду:
int siginterrupt(int sig, int flag) {
int ret;
struct sigaction act;
(void)sigaction(sig, NULL, &act); /* Получить старые установки */
if (flag) /* Если flag равен true... */
act.sa_flags &= ~SA_RESTART; /* Запретить повторный запуск */
else /* В противном случае... */
act.sa_flags |= SA_RESTART; /* Разрешить повторный запуск */
ret = sigaction(sig, &act, NULL);
/* Поместить новые установки на место */
return ret; /* Вернуть результат */
}
В случае успеха возвращаемое значение равно 0 и -1 при ошибке.
10.6.7. Передача сигналов: kill()
и killpg()
Традиционная функция Unix для передачи сигналов называется
kill()
. Имя несколько неправильное; все, что она делает — отправляет сигнал. (Результатом этого часто является завершение получателя сигнала, но это не обязательно верно. Однако, теперь слишком поздно менять имя.) Функция killpg()
посылает сигнал определенной группе процессов. Объявления следующие:
#include /* POSIX */
#include
int kill(pid_t pid, int sig);
int killpg(int pgrp, int sig); /* XSI */
Аргумент
sig
является либо именем сигнала, либо 0. В последнем случае сигнал не посылается, но ядро все равно осуществляет проверку ошибок. В частности, это правильный способ проверки существования данного процесса или группы, а также проверки того, что у вас есть разрешение на передачу сигналов процессу или группе процессов kill()
возвращает 0 в случае успеха и -1 при ошибке; errno
указывает на проблему.
Правила для значения
pid
несколько запутаны:
pid > 0
pid
является номером процесса, и сигнал посылается этому процессу
pid = 0
Сигнал посылается каждому процессу в группе посылающего процесса.
pid = -1
Сигнал посылается каждому процессу в системе, за исключением специальных системных процессов. Применяется проверка прав доступа. На системах GNU/Linux исключается лишь процесс init
(PID 1), но у других систем могут быть другие специальные процессы.
pid < -1
Сигнал посылается группе процессов, представленной абсолютным значением pid
. Таким образом, вы можете отправить сигнал всей группе процессов, дублируя возможности killpg()
. Эта неортогональность обеспечивает историческую совместимость.
Значение
pid
для kill()
сходно со значением для waitpid()
(см. раздел 9.1.6.1 «Использование функций POSIX: wait()
и waitpid()
»).
Стандартная функция С
raise()
в сущности эквивалентна
int raise(int sig) {
return kill(getpid(), sig);
}
Комитет по стандартизации С выбрал имя
raise()
, поскольку С должен работать также в окружениях, не относящихся к Unix, a kill()
была сочтена специфичной для Unix функцией. Представилась также возможность дать этой функции более описательное имя.
killpg()
посылает сигнал группе процессов. Пока значение pgrp
превышает 1, эта функция эквивалентна 'kill(-pgrp, sig)
'. Справочная страница GNU/Linux killpg(2) утверждает, что если pgrp
равно 0, сигнал посылается группе отправляющего процесса (Это то же самое, что и kill()
.)
Как вы могли представить, нельзя послать сигнал произвольному процессу (если вы не являетесь суперпользователем,
root
). Для обычных пользователей действительный или эффективный UID отправляющего процесса должен соответствовать действительному или сохраненному set-user-ID получающего процесса. (Различные UID описаны в разделе 11.1.1 «Действительные и эффективные ID».)
Однако
SIGCONT
является особым случаем: пока получающий процесс является членом того же сеанса, что и отправляющий, сигнал пройдет. (Сеансы были кратко описаны в разделе 9.2.1 «Обзор управления заданиями».) Это особое правило позволяет управляющей заданиями оболочке продолжать остановленные процессы-потомки, даже если этот остановленный процесс имеет другой ID пользователя.
10.6.8. Наша история до настоящего времени, эпизод II
System V Release 3 API был предназначен для исправления различных проблем, представленных первоначальным API сигналов V7. В частности, важной дополнительной концепцией является понятие о блокировке сигналов.
Однако, этот API оказался недостаточным, поскольку он работал лишь с одним сигналом за раз, оставляя множество широко открытых окон, через которые могли поступать нежелательные сигналы. POSIX API, работая атомарно с множеством сигналов (маской сигналов процесса, программно представленной типом
sigset_t
), решает эту проблему, закрывая окна.
Первый набор функций, который мы исследовали, манипулирует значениями
sigset_t
: sigfillset()
, sigemptyset()
, sigaddset()
, sigdelset()
и sigismember()
.
Следующий набор работает с маской сигналов процесса:
sigprocmask()
устанавливает и получает маску сигналов процесса, sigpending()
получает набор ожидающих сигналов, a sigsuspend()
помещает процесс в состояние сна, временно заменяя маску сигналов процесса одним из своих параметров.
Функция POSIX API
sigaction()
(весьма) запутана из-за необходимости обеспечить:
• обратную совместимость:
SA_RESETHAND
и SA_RESTART
в поле sa_flags
;
• выбор, блокировать также полученный сигнал или нет:
SA_NODEFER
для sa_flags
;
• возможность иметь два различных вида обработчиков сигналов: с одним или с тремя аргументами;
• выбор поведения для управления
SIGCHLD
: SA_NOCLDSTOP
и SA_NOCLDWAIT
для sa_flags
.
Функция
siginterrupt()
является удобной для разрешения или запрещения повторного запуска системных вызовов для данного сигнала.
Наконец, для посылки сигналов не только текущему, но также и другим процессам могут использоваться
kill()
и killpg()
(конечно, с проверкой прав доступа).
10.7. Сигналы для межпроцессного взаимодействия
«ЭТО УЖАСНАЯ МЫСЛЬ! СИГНАЛЫ НЕ ПРЕДНАЗНАЧЕНЫ ДЛЯ ЭТОГО! Просто скажите НЕТ».
Одним из главных механизмов межпроцессного взаимодействия (IPC) являются каналы, которые описаны в разделе 9.3 «Базовая межпроцессная коммуникация каналы и FIFO». Сигналы также можно использовать для очень простого IPC[111]. Это довольно грубо; получатель может лишь сказать, что поступил определенный сигнал. Хотя функция
sigaction()
позволяет получателю узнать PID и владельца процесса, пославшего сигнал, эти сведения обычно не очень помогают.
ЗАМЕЧАНИЕ. Как указывает цитата в начале, использование сигналов для IPC почти всегда является плохой мыслью. Мы рекомендуем по возможности избегать этого. Но нашей целью является научить вас, как использовать возможности Linux/Unix, включая их отрицательные моменты, оставляя за вами принятие информированного решения, что именно использовать.
Сигналы в качестве IPC для многих программ могут быть иногда единственным выбором. В частности, каналы не являются альтернативой, если две взаимодействующие программы не запущены общим родителем, а файлы FIFO могут не быть вариантом, если одна из взаимодействующих программ работает лишь со стандартными вводом и выводом. (Примером обычного использования сигналов являются определенные системные программы демонов, таких, как
xinetd
, которые принимают несколько сигналов, уведомляющих, что нужно повторно прочесть файл настроек, осуществить проверку непротиворечивости и т.д. См. xinetd(8) в системе GNU/Linux и inetd(8) в системе Unix.)
Типичная высокоуровневая структура основанного на сигналах приложения выглядит таким образом:
for(;;){
/* Ожидание сигнала */
/* Обработка сигнала */
}
Оригинальным интерфейсом V7 для ожидания сигнала является
pause()
:
#include /* POSIX */
int pause(void);
pause()
приостанавливает процесс; она возвращается лишь после того, как сигнал будет доставлен и его обработчик вернется из вызова. По определению, pause()
полезна лишь с перехваченными сигналами — игнорируемые сигналы при их появлении игнорируются, а сигналы с действием по умолчанию, завершающим процесс (с созданием файла образа или без него), продолжают действовать так же.
Проблема в только что описанной высокоуровневой структуре приложения кроется в части «Обработка сигнала». Когда этот код запускается, вы не захотите обрабатывать другой сигнал; вы хотите завершить обработку текущего сигнала до перехода к следующему. Одним из возможных решений является структурирование обработчика сигнала таким образом, что он устанавливает флаг и проверяет его в главном цикле:
volatile sig_atomic_t signal_waiting = 0; /* true, если не обрабатываются сигналы */
void handler(int sig) {
signal_waiting = 1;
/* Установка других данных, указывающих вид сигнала */
В основном коде флаг проверяется:
for (;;) {
if (!signal_waiting) { /* Если возник другой сигнал, */
pause(); /* этот код пропускается */
signal_waiting = 1;
}
/* Определение поступившего сигнала */
signal_waiting = 0;
/* Обработка сигнала */
}
К сожалению, этот код изобилует условиями гонки:
for (;;) {
if (!signal_waiting) {
/* <--- Сигнал может появиться здесь, после проверки условия! */
pause(); /* pause() будет вызвана в любом случае */
signal_waiting = 1;
}
/* Определение поступившего сигнала
<--- Сигнал может переписать здесь глобальные данные */
signal_waiting = 0;
/* Обработка сигнала
<--- То же и здесь, особенно для нескольких сигналов */
}
Решением является блокирование интересующего сигнала в любое время, кроме ожидания его появления. Например, предположим, что интересующим нас сигналом является
SIGINT
:
void handler(int sig) {
/* sig автоматически блокируется функцией sigaction() */
/* Установить глобальные данные, касающиеся этого сигнала */
}
int main(int argc, char **argv) {
sigset_t set;
struct sigaction act;
/* ...обычная настройка, опции процесса и т.д. ... */
sigemptyset(&set); /* Создать пустой набор */
sigaddset(&set, SIGINT); /* Добавить в набор SIGINT */
sigprocmask(SIG_BLOCK, &set, NULL); /* Заблокировать его */
act.sa_mask = set; /* Настроить обработчик */
act.sa_handler = handler;
act.sa_flags = 0;
sigaction(sig, &act, NULL); /* Установить его */
... /* Возможно, установить отдельные обработчики */
... /* для других сигналов */
sigemptyset(&set); /* Восстановить пустой, допускает SIGINT */
for (;;) {
sigsuspend(&set); /* Ждать появления SIGINT */
/* Обработка сигнала. SIGINT здесь снова блокируется */
}
/* ...любой другой код... */
return 0;
}
Ключом к использованию этого является то, что
sigsuspend()
временно заменяет маску сигналов процесса маской, переданной в аргументе. Это дает SIGINT
возможность появиться. При появлении он обрабатывается; обработчик сигнала возвращается, а вслед за ним возвращается также sigsuspend()
. Ко времени возвращения sigsuspend()
первоначальная маска процесса снова на месте.
Вы легко можете расширить этот пример для нескольких сигналов, блокируя в
main()
и в обработчике все интересующие сигналы и разблокируя их лишь в вызове sigsuspended()
.
При наличии всего этого не следует в новом коде использовать
pause()
. pause()
был стандартизован POSIX главным образом для поддержки старого кода. То же самое верно и для функции sigpause()
System V Release 3. Вместо этого, если нужно структурировать свое приложение с использованием сигналов для IPC, используйте исключительно функции API sigsuspend()
и sigaction()
.
ЗАМЕЧАНИЕ. Приведенный выше код предполагает, что маска сигналов процесса начинается пустой. Код изделия должен вместо этого работать с любой маской сигналов, имеющейся на момент запуска программы.
10.8. Важные сигналы специального назначения
Некоторые сигналы имеют особое назначение. Здесь мы опишем наиболее важные.
10.8.1. Сигнальные часы: sleep()
, alarm()
и SIGALARM
Часто бывает необходимо написать программу в виде
while (/* некоторое неверное условие */) {
/* подождать некоторое время */
}
Часто такая потребность возникает в сценариях оболочки, например, в ожидании регистрации определенного пользователя:
until who | grep '^arnold' > /dev/null
do
sleep 10
done
Два механизма, один низкоуровневый, другой высокоуровневый, позволяют работающему процессу узнать, когда истекло заданное количество секунд.
10.8.1.1. Труднее, но с большим контролем: alarm()
и SIGALARM
Основным строительным блоком является системный вызов
alarm()
:
#include /* POSIX */
unsigned int alarm(unsigned int seconds);
После того, как
alarm()
возвратится, программа продолжает работать. Однако, когда истекают seconds
секунд, ядро посылает процессу SIGALARM
. Действием по умолчанию является завершение процесса, но вы скорее всего вместо этого установите обработчик сигнала для SIGALARM
.
Возвращаемое значение либо 0, либо, если был установлен предыдущий сигнальный интервал, число секунд, остающихся до его завершения. Однако, для процесса имеется лишь один такой сигнальный интервал; предыдущий отменяется, а новый помещается на его место.
Преимуществом здесь является то, что со своим установленным обработчиком вы можете делать при поступлении сигнала все, что хотите. Недостаток же в том, что приходится быть готовым к работе в нескольких контекстах: основном контексте и контексте обработчика сигнала.
10.8.1.2. Простой и легкий: sleep()
Более легкий способ ожидания истечения фиксированного промежутка времени заключается в использовании функции
sleep()
:
#include /* POSIX */
unsigned int sleep(unsigned int seconds);
Возвращаемое значение равно 0, если процесс проспал все отведенное время. В противном случае возвращается оставшееся для сна время. Это последнее значение может возникнуть в случае, если появился сигнал, пока процесс дремал.
ЗАМЕЧАНИЕ. Функция
sleep()
часто реализуется через сочетание signal()
, alarm()
и pause()
. Такой подход делает опасным смешивание sleep()
с вашим собственным вызовом alarm()
(или расширенной функцией setitimer()
, описанной в разделе 14.3.3 «Интервальные таймеры setitimer()
и getitimer()
») Чтобы теперь узнать о функции nanosleep()
, см. раздел 14.3.4 «Более точные паузы: nanosleep()
».
10.8.2. Сигналы, управляющие заданиями
Несколько сигналов используются для реализации управления заданиями — возможностью начинать и останавливать задания и перемещать их из фонового режима на передний план и обратно. На уровне пользователя вы, несомненно, проделывали это: использовали CTRL-Z для остановки задания,
bg
для помещения его в фоновый режим, а иногда использовали fg
для перемещения фонового или остановленного задания на передний план.
Секция 9.2.1 «Обзор управления заданиями» описывает в общем, как осуществляется управление заданиями. Данный раздел завершает обзор, описав сигналы управления заданиями. поскольку иногда может понадобиться перехватить их непосредственно:
SIGTSTP
Этот сигнал осуществляет «остановку терминала». Это сигнал, который ядро посылает процессу, когда пользователь за терминалом (или окном, эмулирующим терминал) набирает определенный ключ. Обычно это CTRL-Z, аналогично тому, как CTRL-C обычно посылает
SIGINT
.
Действием по умолчанию для
SIGTSTP
является остановка (переход в приостановленное состояние) процесса. Однако, вы можете перехватить этот сигнал, как любой другой. Хорошая мысль сделать это, если ваша программа изменяет состояние терминала. Например, рассмотрите экранные редакторы vi
или Emacs, которые переводят терминал в посимвольный режим. По получении SIGTSTP
, они должны восстановить терминал в его нормальный построчный режим, а затем приостановиться сами.
SIGSTOP
Этот сигнал также останавливает процесс, но он не может быть перехвачен, заблокирован или проигнорирован. Он может быть использован в качестве последнего средства вручную (посредством команды
kill
) или программным путем. Например, только что обсужденный обработчик SIGTSTP
после восстановления состояния терминала мог бы затем использовать для остановки процесса 'raise (SIGSTOP)
'.
SIGTTIN
, SIGTTOU
Ранее эти сигналы были определены как «фоновое чтение из tty» и «фоновая запись в tty». tty является устройством терминала. В системах управления заданиями процессы, работающие в фоновом режиме, заблокированы от попыток чтения с терминала или записи в него. Когда процесс пытается осуществить любую из этих операций, ядро посылает ему соответствующий сигнал. Для обоих действием по умолчанию является остановка процесса. При желании можно перехватить эти сигналы, но для этого редко бывает необходимость.
SIGCONT
Этот сигнал вновь запускает остановленный процесс. Если процесс не остановлен, он игнорируется. При желании его можно перехватить, но опять-таки для большинства программ мало причин для осуществления этого. Продолжая наш пример, обработчик
SIGCONT
для экранного редактора должен перед возвращением вернуть терминал обратно в посимвольный режим.
Когда процесс остановлен, любые другие посланные ему сигналы становятся ожидающими. Исключением является
SIGKILL
, который всегда доставляется процессу и который не может быть перехвачен, заблокирован или проигнорирован. В предположении, что были посланы сигналы кроме SIGKILL
, по получении SIGCONT
ожидающие сигналы доставляются, а процесс продолжает выполнение после того, как они будут обработаны.
10.8.3. Родительский надзор: три различные стратегии
Как описано в разделе 9.1.1 «Создание процесса:
fork()
», одним побочным эффектом вызова fork()
является создание между процессами отношений родитель-потомок. Родительский процесс может ждать завершения одного или более из своих потомков и получить статус завершения порожденного процесса посредством одного из семейства системных вызовов wait()
.
Завершившиеся порожденные процессы, которых никто не ожидал, называются зомби (zombies). Обычно каждый раз при завершении порожденного процесса ядро посылает родительскому процессу сигнал
SIGCHLD
[112]. Действием по умолчанию является игнорирование этого сигнала. В этом случае процессы зомби накапливаются до тех пор, пока родитель не вызовет wait()
или не закончится сам. В последнем случае процессы зомби получают в качестве нового родителя системный процесс init
(PID 1), который получает от них результаты как часть своей обычной работы. Сходным образом, активные потомки также получают родителем init
, и их результаты будут собраны при их завершении.
SIGCHLD
используется для большего, чем уведомление о завершении потомка. Каждый раз при остановке потомка (посредством одного из обсужденных ранее сигналов управления заданиями) родителю также посылается SIGCHLD
. Стандарт POSIX указывает, что SIGCHLD
«может быть послан» также, когда помок вновь запускается; очевидно, среди оригинальных Unix-систем имеются различия.
Сочетание флагов для поля
sa_flags
в struct sigation
и использование SIG_IGN
в качестве действия для SIGCHLD
позволяет изменить способ обработки ядром остановок, возобновления или завершения потомков.
Как и с сигналами в общем, описанные здесь интерфейсы и механизмы сложны, поскольку они развивались с течением времени.
10.8.3.1. Плохие родители: полное игнорирование потомков
Простейшим действием, которое вы можете сделать, является изменение действия для
SIGCHLD
на SIG_IGN
. В этом случае завершившиеся потомки не становятся зомби. Вместо этого статус их завершения отбрасывается, и они полностью удаляются из системы.
Другой возможностью, дающей такой же результат, является использование флага
SA_NOCLDWAIТ
. В коде:
/* Старый стиль: */ /* Новый стиль: */
signal(SIGCHLD, SIG_IGN); struct sigaction sa;
sa.sa_handler = SIG_IGN;
sa.sa_flags = SA_NOCLDWAIT;
sigemptyset(&sa.sa_mask);
sigaction(SIGCHLD, &sa, NULL);
10.8.3.2. Снисходительные родители: минимальный надзор
В качестве альтернативы можно беспокоиться лишь о завершении потомка и не интересоваться простыми изменениями состояния (остановке и возобновлении). В этом случае используйте флаг
SA_NOCLDSTOP
и установите обработчик сигнала, вызывающий wait()
(или родственную ей функцию) для получения данных процесса.
В общем вы не можете ожидать получать по одному сигналу
SIGCHLD
на каждого завершающегося потомка. Следует считать, что SIGCHLD
означает «завершился по крайней мере один потомок» и быть готовым собрать при обработке SIGCHLD
сведения о как можно большем числе потомков.
Следующая программа,
ch10-reap1.с
, блокирует SIGCHLD
до тех пор, пока не будет готова восстановить потомков.
1 /* ch10-reap1.с --- демонстрирует управление SIGCHLD с использованием цикла */
2
3 #include
4 #include
5 #include
6 #include
7 #include
8 #include
9
10 #define MAX_KIDS 42
11 #define NOT_USED -1
12
13 pid_t kids[MAX_KIDS];
14 size_t nkids = 0;
Массив потомков отслеживает ID порожденных процессов. Если элемент содержит
NOT_USED
, он не представляет необработанного потомка. (Его инициализируют строки 89–90 внизу) nkids
указывает, сколько значений в kids
следует проверить.
16 /* format_num --- вспомогательная функция, поскольку нельзя использовать [sf]printf() */
17
18 const char *format_num(int num)
19 {
20 #define NUMSIZ 30
21 static char buf[NUMSIZ];
22 int i;
23
24 if (num <= 0) {
25 strcpy(buf, "0");
26 return buf;
27 }
28
29 i = NUMSIZ - 1;
30 buf[i--] = '\0';
31
32 /* Преобразует цифры обратно в строку. */
33 do {
34 buf[i--] = (num % 10) + '0';
35 num /= 10;
36 } while (num > 0);
37
38 return &buf[i+1];
39 }
Поскольку обработчики сигналов не должны вызывать функции семейства
printf()
, мы предусмотрели для преобразования десятичного сигнала или номера PID в строку простую «вспомогательную» функцию format_num()
. Это примитивно, но работает.
41 /* childhandler --- перехват SIGCHLD, сбор сведений со всех доступных потомков */
42
43 void childhandler(int sig)
44 {
45 int status, ret;
46 int i;
47 char buf[100];
48 static const char entered[] = "Entered childhandler\n" ;
49 static const char exited[] = "Exited childhandler\n";
50
51 writed, entered, strlen(entered));
52 for (i =0; i < nkids; i++) {
53 if (kids[i] == NOT_USED)
54 continue;
55
56 retry:
57 if ((ret = waitpid(kids[i], &status, WNOHANG)) == kids[i]) {
58 strcpy(buf, "\treaped process ");
59 strcat(buf, format_num(ret));
60 strcat(buf, "\n");
61 write(1, buf, strlen(buf));
62 kids[i] = NOT_USED;
63 } else if (ret == 0) {
64 strcpy(buf, "\tpid ");
65 strcat(buf, format_num(kids[i]));
66 strcat(buf, " not available yet\n");
67 write(1, buf, strlen(buf));
68 } else if (ret == -1 && errno == EINTR) {
69 write(1, "\tretrying\n", 10);
70 goto retry;
71 } else {
72 strcpy(buf, "\twaitpid() failed: ");
73 strcat(buf, strerror(errno));
74 strcat(buf, "\n");
75 write(1, buf, strlen(buf));
76 }
77 }
78 write(1, exited, strlen(exited));
79 }
Строки 51 и 58 выводят «входное» и «завершающее» сообщения, так что мы можем ясно видеть, когда вызывается обработчик сигнала. Другие сообщения начинаются с ведущего символа TAB.
Главной частью обработчика сигнала является большой цикл, строки 52–77. Строки 53–54 проверяют на
NOT_USED
и продолжают цикл, если текущий слот не используется.
Строка 57 вызывает
waitpid()
с PID текущего элемента kids
. Мы предусмотрели опцию WNOHANG
, которая заставляет waitpid()
возвращаться немедленно, если затребованный потомок недоступен. Этот вызов необходим, так как возможно, что не все потомки завершились.
Основываясь на возвращенном значении, код предпринимает соответствующее действие. Строки 57–62 обрабатывают случай обнаружения потомка, выводя сообщение и помещая в соответствующий слот в
kids
значение NOT_USED
.
Строки 63–67 обрабатывают случай, когда затребованный потомок недоступен. В этом случае возвращается значение 0, поэтому выводится сообщение, и выполнение продолжается.
Строки 68–70 обрабатывают случай, при котором был прерван системный вызов. В этом случае самым подходящим способом обработки является
goto
обратно на вызов waitpid()
. (Поскольку main()
блокирует все сигналы при вызове обработчика сигнала [строка 96], это прерывание не должно случиться. Но этот пример показывает, как обработать все случаи.)
Строки 71–76 обрабатывают любую другую ошибку, выводя соответствующее сообщение об ошибке.
81 /* main --- установка связанных с порожденными процессами сведений и сигналов, создание порожденных процессов */
82
83 int main(int argc, char **argv)
84 {
85 struct sigaction sa;
86 sigset_t childset, emptyset;
87 int i;
88
89 for (i = 0; i < nkids; i++)
90 kids[i] = NOT_USED;
91
92 sigemptyset(&emptyset);
93
94 sa.sa_flags =
SA_NOCLDSTOP;
95 sa.sa_handler = childhandler;
96 sigfillset(&sa.sa_mask); /* блокировать все при вызове обработчика */
97 sigaction(SIGCHLD, &sa, NULL);
98
99 sigemptyset(&childset);
100 sigaddset(&childset, SIGCHLD);
101
102 sigprocmask(SIG_SETMASK, &childset, NULL); /* блокировать его в коде main */
103
104 for (nkids = 0; nkids < 5; nkids++) {
105 if ((kids[nkids] = fdrk()) == 0) {
106 sleep(3);
107 _exit(0);
108 }
109 }
110
111 sleep(5); /* дать потомкам возможность завершения */
112
113 printf("waiting for signal\n");
114 sigsuspend(&emptyset);
115
116 return 0;
117 }
Строки 89–90 инициализируют
kids
. Строка 92 инициализирует emptyset
. Строки 94–97 настраивают и устанавливают обработчик сигнала для SIGCHLD
. Обратите внимание на использование в строке 94 SA_NOCLDSTOP
, тогда как строка 96 блокирует все сигналы при вызове обработчика.
Строки 99–100 создают набор сигналов, представляющих
SIGCHLD
, а строка 102 устанавливает их в качестве маски сигналов процесса для программы.
Строки 104–109 создают пять порожденных процессов, каждый из которых засыпает на три секунды. По ходу дела они обновляют массив
kids
и переменную nkids
.
Строка 111 дает затем потомкам шанс завершиться, заснув на еще больший промежуток времени. (Это не гарантирует, что порожденные процессы завершатся, но шансы довольно велики.)
Наконец, строки 113–114 выводят сообщение и приостанавливаются, заменив маску сигналов процесса, блокирующую
SIGCHLD
, пустой маской. Это дает возможность появиться сигналу SIGCHLD
, что в свою очередь вызывает запуск обработчика сигнала. Вот что происходит:
$ ch10-reap1 /* Запуск программы */
waiting for signal
Entered childhandler
reaped process 23937
reaped process 23938
reaped process 23939
reaped process 23940
reaped process 23941
Exited childhandler
Обработчик сигнала собирает сведения о потомках за один проход.
Следующая программа,
ch10-reap2.c
, сходна с ch10-reap1.c
. Разница в том, что она допускает появление сигнала SIGCHLD
в любое время. Такое поведение увеличивает шанс получения более одного SIGCHLD
, но не гарантирует это. В результате обработчик сигнала все равно должен быть готов обработать в цикле несколько потомков.
1 /* ch10-reap2.c — демонстрирует управление SIGCHLD, один сигнал на потомка */
2
/* ...не изменившийся код пропущен... */
12
13 pid_t kids[MAX_KIDS];
14 size_t nkids = 0;
15 size_t kidsleft = 0; /* <<< Добавлено */
16
/* ...не изменившийся код пропущен... */
41
42 /* childhandler --- перехват SIGCHLD, опрос всех доступных потомков */
43
44 void childhandler(int sig)
45 {
46 int status, ret;
47 int i;
48 char buf[100];
49 static const char entered[] = "Entered childhandler\n";
50 static const char exited[] = "Exited childhandler\n";
51
52 write(1, entered, strlen(entered));
53 for (i = 0; i < nkids; i++) {
54 if (kids[i] == NOT_USED)
55 continue;
56
57 retry:
58 if ((ret = waitpid(kids[i], &status, WNOHANG)) == kids[i]) {
59 strcpy(buf, "\treaped process ");
60 strcat(buf, format_num(ret));
61 strcat(buf, "\n");
62 write(1, buf, strlen(buf));
63 kids[i] = NOT_USED;
64 kidsleft--; /* <<< Добавлено */
65 } else if (ret == 0) {
/* ...не изменившийся код пропущен... */
80 write(1, exited, strlen(exited));
81 }
Это идентично предыдущей версии за тем исключением, что у нас есть новая переменная,
kidsleft
, указывающая, сколько имеется не опрошенных потомков. Строки 15 и 64 помечают новый код.
83 /* main --- установка относящейся к порожденным процессам сведений
и сигналов, создание порожденных процессов */
84
85 int main(int argc, char **argv)
86 {
/* ...не изменившийся код пропущен... */
100
101 sigemptyset(&childset);
102 sigaddset(&childset, SIGCHLD);
103
104 /* sigprocmask(SIG_SETMASK, &childset, NULL); /* блокирование в коде main */
105
106 for (nkids = 0; nkids < 5; nkids++) {
107 if ((kids[nkids] = fork()) == 0) {
108 sleep(3);
109 _exit(0);
110 }
111 kidsleft++; /* <<< Added */
112 }
113
114 /* sleep(5); /* дать потомкам шанс завершиться */
115
116 while (kidsleft > 0) { /* <<< Добавлено */
117 printf("waiting for signals\n");
118 sigsuspend(&emptyset);
119 } /* <<< Добавлено */
120
121 return 0;
122 }
Здесь код также почти идентичен. Строки 104 и 114 закомментированы из предыдущей версии, а строки 111, 116 и 119 добавлены. Удивительно, при запуске поведение меняется в зависимости от версии ядра!
$ uname -a /* Отобразить версию системы */
Linux example1 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 GNU/Linux
$ ch10-reap2 /* Запустить программу */
waiting for signals
Entered childhandler /* Опрос одного потомка */
reaped process 2702
pid 2703 not available yet
pid 2704 not available yet
pid 2705 not available yet
pid 27 06 not available yet
Exited childhandler
waiting for signals
Entered childhandler /* И следующего */
reaped process 2703
pid 2704 not available yet
pid 2705 not available yet
pid 2706 not available yet
Exited childhandler
waiting for signals
Entered childhandler /* И так далее */
reaped process 2704
pid 2705 not available yet
pid 2706 not available yet
Exited childhandler
waiting for signals
Entered childhandler
reaped process 2705
pid 2706 not available yet
Exited childhandler
waiting for signals
Entered childhandler
reaped process 2706
Exited childhandler
В данном примере на каждый процесс поступает ровно один
SIGCHLD
! Хотя это прекрасно и полностью воспроизводимо на этой системе, это также необычно. Как на более раннем, так и на более позднем ядре и на Solaris программа получает один сигнал для более чем одного потомка:
$ uname -a /* Отобразить версию системы */
Linux example2 2.4.22-1.2115.npt1 #1 Wed Oct 29 15:42:51 EST 2003 i686 i686 i386 GNU/Linux
$ ch10-reap2 /* Запуск программы */
waiting for signals
Entered childhandler /* Обработчик сигнала вызван лишь однажды */
reaped process 9564
reaped process 9565
reaped process 9566
reaped process 9567
reaped process 9568
Exited childhandler
ЗАМЕЧАНИЕ. В коде для
ch10-reap2.c
есть один важный дефект — состояние гонки. Взгляните еще раз на строки 106–112 в ch10-reap2.c
. Что случится, если SIGCHLD
появится при исполнении этого кода? Массив kids
и переменные nkids
и kidsleft
могут оказаться разрушенными: код в main
добавляет новый процесс, но обработчик сигнала вычитает один.
Этот пример кода является отличным примером критического раздела; он не должен прерываться при исполнении. Правильным способом работы с этим кодом является заключение его между вызовами, которые сначала блокируют, а затем разблокируют
SIGCHLD
.
10.8.3.3. Строгий родительский контроль
Структура
siginfo_t
и перехватчик сигнала с тремя аргументами дают возможность узнать, что случилось с потомком. Для SIGCHLD поле si_code
структуры siginfo_t
указывает причину посылки сигнала (остановка, возобновление, завершение порожденного процесса и т.д.). В табл. 10.5 представлен полный список значений. Все они определены в качестве расширения XSI стандарта POSIX.
Следующая программа,
ch10-status.c
, демонстрирует использование структуры siginfo_t
.
1 /* ch10-status.c --- демонстрирует управление SIGCHLD, используя обработчик с 3 аргументами */
2
3 #include
4 #include
5 #include
6 #include
7 #include
8 #include
9
10 void manage(siginfo_t *si);
11
/* ...не изменившийся для format_num() код опущен... */
Таблица 10.5. Значения
si_code
XSI для SIGCHLD
Значение
Смысл
CLD_CONTINUED
Остановленный потомок был возобновлен.
CLD_DUMPED
Потомок завершился с ошибкой, создан образ процесса
CLD_EXITED
Потомок завершился нормально.
CLD_KILLED
Потомок был завершен сигналом
CLD_STOPPED
Порожденный процесс был остановлен.
CLD_TRAPPED
Трассируемый потомок остановлен (Это условие возникает, когда программа трассируется — либо из отладчика, либо для мониторинга реального времени В любом случае, вы вряд ли увидите его в обычных ситуациях.)
Строки 3–8 включают стандартные заголовочные файлы, строка 10 объявляет
manage()
, которая имеет дело с изменениями состояния потомка, а функция format_num()
не изменилась по сравнению с предыдущим.
37 /* childhandler --- перехват SIGCHLD, сбор данных лишь об одном потомке */
38
39 void childhandler(int sig, siginfo_t *si, void *context)
40 {
41 int status, ret;
42 int i;
43 char buf[100];
44 static const char entered[] = "Entered childhandler\n";
45 static const char exited[] = "Exited childhandler\n";
46
47 write(1, entered, strlen(entered));
48 retry:
49 if ((ret = waitpid(si->si_pid, &status, WNOHANG)) == si->si_pid) {
50 strcpy(buf, "\treaped process ");
51 strcat(buf, format_num(si->si_pid));
52 strcat(buf, "\n");
53 write(1, buf, strlen(buf));
54 manage(si); /* обработать то, что произошло */
55 } else if (ret > 0) {
56 strcpy(buf, "\treaped unexpected pid ");
57 strcat(buf, format_num(ret));
58 strcat(buf, "\n");
59 write(1, buf, strlen(buf));
60 goto retry; /* почему бы нет? */
61 } else if (ret == 0) {
62 strcpy(buf, "\tpid ");
63 strcat(buf, format_num(si->si_pid));
64 strcat(buf, " changed status\n");
65 write(1, buf, strlen(buf));
66 manage(si); /* обработать то, что произошло */
67 } else if (ret == -1 && errno == EINTR) {
68 write(1, "\tretrying\n", 10);
69 goto retry;
70 } else {
71 strcpy(buf, "\twaitpid() failed: ");
72 strcat(buf, strerror(errno));
73 strcat(buf, "\n");
74 write(1, buf, strlen(buf));
75 }
76
77 write(1, exited, strlen(exited));
78 }
Обработчик сигнала похож на показанные ранее. Обратите внимание на список аргументов (строка 39) и на то, что нет цикла.
Строки 49–54 обрабатывают завершение процесса, включая вызов
manage()
для вывода состояния.
Строки 55–60 обрабатывают случай неожиданного завершения потомка. Этого не должно происходить, поскольку обработчику сигнала передается специфическая для определенного порожденного процесса информация.
Строки 61–66 представляют для нас интерес: возвращаемое значение для изменений состояния равно 0.
manage()
имеет дело с деталями (строка 66).
Строки 67–69 обрабатывают прерывания, а строки 70–75 распоряжаются ошибками
80 /* child --- что сделать в порожденном процессе */
81
82 void child(void)
83 {
84 raise(SIGCONT); /* должен быть проигнорирован */
85 raise(SIGSTOP); /* заснуть, родитель снова разбудит */
86 printf("\t---> child restarted <---\n");
87 exit(42); /* нормальное завершение, дать возможность родителю получить значение */
88 }
Функция
child()
обрабатывает поведение порожденного процесса, предпринимая действия для уведомления родителя[113]. Строка 84 посылает SIGCONT
, что может вызвать получение родителем события CLD_CONTINUED
. Строка 85 посылает SIGSTOP
, который останавливает процесс (сигнал не может быть перехвачен) и вызывает для родителя событие CLD_STOPPED
. Когда родитель возобновляет порожденный процесс, последний выводит сообщение, что он снова активен, а затем завершается с известным статусом завершения.
90 /* main --- установка относящихся к порожденному процессу сведений
и сигналов, создание порожденного процесса */
91
92 int main(int argc, char **argv)
93 {
94 pid_t kid;
95 struct sigaction sa;
96 sigset_t childset, emptyset;
97
98 sigemptyset(&emptyset);
99
100 sa.sa_flags = SA_SIGINFO;
101 sa.sa_sigaction = childhandler;
102 sigfillset(&sa.sa_mask); /* при вызове обработчика все заблокировать */
103 sigaction(SIGCHLD, &sa, NULL);
104
105 sigemptyset(&childset);
106 sigaddset(&childset, SIGCHLD);
107
108 sigprocmask(SIG_SETMASK, &childset, NULL); /* блокировать его в коде main */
109
110 if ((kid = fork()) == 0)
111 child();
112
113 /* здесь выполняется родитель */
114 for (;;) {
115 printf("waiting for signals\n");
116 sigsuspend(&emptyset);
117 }
118
119 return 0;
120 }
Программа
main()
все устанавливает. Строки 100–103 помещают на место обработчик. Строка 100 устанавливает флаг SA_SIGINFO
таким образом, что используется обработчик с тремя аргументами. Строки 105–108 блокируют SIGCHLD
.
Строка 110 создает порожденный процесс. Строки 113–117 продолжаются в родителе, используя для ожидания входящих сигналов
sigsuspend()
.
123 /* manage --- разрешение различных событий, которые могут случиться с потомком */
124
125 void manage(siginfo_t *si)
126 {
127 char buf[100];
128
129 switch (si->si_code) {
130 case CLD_STOPPED:
131 write(1, "\tchild stopped, restarting\n", 27);
132 kill(si->si_pid, SIGCONT);
133 break;
134
135 case CLD_CONTINUED: /* not sent on Linux */
136 write(1, "\tchild continued\n", 17);
137 break;
138
139 case CLD_EXITED:
140 strcpy(buf, "\tchild exited with status ");
141 strcat(buf, format_num(si->si_status));
142 strcat(buf, "\n");
143 write(1, buf, strlen(buf));
144 exit(0); /* we're done */
145 break;
146
147 case CLD_DUMPED:
148 write(1, "\tchild dumped\n", 14);
149 break;
150
151 case CLD_KILLED:
152 write(1, " \tchild killed\n", 14);
153 break;
154
155 case CLD_TRAPPED:
156 write(1, "\tchild trapped\n", 15);
157 break;
158 }
159 }
Посредством функции
manage()
родитель обрабатывает изменение состояния в порожденном процессе, manage()
вызывается, когда изменяется состояние и когда порожденный процесс завершился.
Строки 130–133 обрабатывают случай, когда потомок остановился; родитель возобновляет его, посылая
SIGCONT
.
Строки 135–137 выводят уведомление о возобновлении потомка. Это событие на системах GNU/Linux не происходит, и стандарт POSIX использует в этом случае невыразительный язык, просто говоря, что это событие может появиться, а не появится.
Строки 139–145 обрабатывают случай, когда порожденный процесс завершается, выводя статус завершения. Для этой программы родитель также все сделал, поэтому код завершается, хотя в более крупной программе это не то действие, которое должно быть сделано.
Другие случаи более специализированные. В случае события
CLD_KILLED
для получения дополнительных сведений было бы полезным значение status
, заполненной функцией waitpid()
.
Вот что происходит при запуске:
$ ch10-status /* Запуск программы */
waiting for signals
Entered childhandler /* Вход в обработчик сигнала */
pid 24279 changed status
child stopped, restarting /* Обработчик действует */
Exited childhandler
waiting for signals
---> child restarted <--- /* Из потомка */
Entered childhandler
reaped process 24279 /* Обработчик родителя опрашивает потомка */
child exited with status 42
К сожалению, поскольку нет способа гарантировать доставку по одному
SIGCHLD
на каждый процесс, ваша программа должна быть готова восстановить несколько потомков за один проход.
10.9. Сигналы, передающиеся через fork()
и exec()
Когда программа вызывает
fork()
, ситуация с сигналами в порожденном процессе почти идентична ситуации в родительском процессе. Установленные обработчики остаются на месте, заблокированные сигналы остаются заблокированными и т.д. Однако, любые ожидающие в родителе сигналы в потомке сбрасываются, включая установленный с помощью alarm()
временной интервал. Это просто, и это имеет смысл.
Когда процесс вызывает одну из функций
exec()
, положение в новой программе следующее:
• Сигналы с установленным действием по умолчанию остаются с этим действием по умолчанию.
• Все перехваченные сигналы сбрасываются в состояние с действием по умолчанию.
• Сигналы, которые игнорируются, продолжают игнорироваться. Особым случаем является
SIGCHLD
. Если SIGCHLD
до вызова exec()
игнорировался, он может игнорироваться также и после вызова. В качестве альтернативы для него может быть восстановлено действие по умолчанию. То, что происходит на самом деле, стандартом POSIX намеренно не определяется. (Справочные страницы GNU/Linux не определяют, что делает Linux, и поскольку POSIX оставляет это не определенным, любой код, который вы пишете для использования SIGCHLD
, должен быть подготовлен для обработки любого случая.)
• Сигналы, заблокированные до вызова
exec()
, остаются заблокированными и после вызова. Другими словами, новая программа наследует маску сигналов существующего процесса.
• Любые ожидающие сигналы (те, которые появились, но были заблокированы) сбрасываются. Новая программа не может их получить.
• Временной интервал, остающийся для
alarm()
, сохраняется на своем месте. (Другими словами, если процесс устанавливает alarm
, а затем непосредственно вызывает exec()
, новый образ в конечном счете получит SIGALARM
. Если он сначала вызывает fork()
, родитель сохраняет установки alarm
, тогда как потомок, вызывающий exec()
, не сохраняет.
ЗАМЕЧАНИЕ. Многие, если не все. программы предполагают, что сигналы инициализированы действиями по умолчанию и что заблокированных сигналов нет. Таким образом, особенно если не вы писали программу, запускаемую с помощью
exec()
, можно разблокировать перед вызовам exec()
все сигналы
10.10. Резюме
«Наша история до настоящего времени, эпизод III»
• Интерфейсы обработки сигналов развились от простых, но подверженных состояниям гонок, до сложных, но надежных. К сожалению, множественность интерфейсов затрудняет их изучение по сравнению с другими API Linux/Unix.
• У каждого сигнала есть связанное с ним действие. Действие может быть одним из следующих: игнорирование сигнала; выполнение действия системы по умолчанию или вызов предоставленного пользователем обработчика. Действие системы по умолчанию, в свою очередь, является одним из следующих: игнорирование сигнала, завершение процесса; завершение процесса с созданием его образа; остановка процесса или возобновление процесса, если он остановлен.
•
signal()
и raise()
стандартизованы ISO С. signal()
управляет действиями для определенных сигналов; raise()
посылает сигнал текущему процессу. Остаются ли обработчики сигналов установленными после вызова или сбрасываются для действия по умолчанию, зависит от реализации, signal()
и raise()
являются простейшими интерфейсами, для многих приложений их достаточно.
• POSIX определяет функцию
bsd_signal()
, которая подобна signal()
, но гарантирует, что обработчик остается установленным.
• Действия, происходящие после возвращения из обработчика, варьируют в зависимости от системы. Традиционные системы (V7, Solaris, возможно, и другие) восстанавливают действие сигнала по умолчанию. На этих системах прерванный системный вызов возвращает -1, устанавливая в
errno
значение EINTR
. Системы BSD оставляют обработчик установленным и возвращают -1 с errno
, содержащим EINTR
, лишь в случае, когда не было перемещения данных; в противном случае, системный вызов запускается повторно.
• GNU/Linux придерживается POSIX, который похож, но не идентичен с BSD. Если не было перемещения данных, системный вызов возвращает -1/
EINTR
. В противном случае он возвращает объем перемещенных данных. Поведение BSD «всегда повторный запуск» доступно через интерфейс sigaction()
, но он не является действием по умолчанию.
• Обработчики сигналов, используемые с
signal()
, подвержены состояниям гонок. Внутри обработчиков сигналов должны использоваться исключительно переменные типа volatile sig_atomic_t
. (В целях упрощения в некоторых из наших примеров мы не всегда следовали этому правилу.) Таким же образом, для вызова из обработчика сигналов безопасными являются лишь функции из табл. 10.2.
• Первоначальной попыткой создания надежных сигналов был API сигналов System V Release 3 (скопированный из BSD 4.0). Не используйте его в новом коде.
• POSIX API содержит множество компонентов:
• маску сигналов процесса, перечисляющую текущие заблокированные сигналы;
• тип
sigset_t
для представления масок сигналов, и функции sigfillset()
, sigemptyset()
, sigaddset()
, sigdelset()
и sigismember()
для работы с ними;
• функцию
sigprocmask()
для установки и получения маски сигналов процесса,
• функцию
sigpending()
для получения набора ожидающих сигналов;
• API
sigaction()
и struct sigaction
во всем их великолепии.
Все эти возможности вместе используют блокирование сигналов и маску сигналов процесса для предоставления надежных сигналов. Более того, через различные флаги можно получить повторно запускаемые системные вызовы и более подходящие обработчики сигналов, которые получают большую информацию о причине, вызвавшей определенный сигнал (структура
siginfo_t
).
• Механизмами POSIX для посылки сигналов являются
kill()
и killpg()
. Они отличаются от raise()
в двух отношениях: (1) одни процесс может послать сигнал другому процессу или целой группе процессов (конечно, с проверкой прав доступа), и (2) посылка сигнала 0 ничего не посылает, но осуществляет проверку. Таким образом, эти функции предоставляют способ проверки наличия определенного процесса или группы процессов и возможность посылки ему (им) сигнала.
• Сигналы могут использоваться в качестве механизма IPC, хотя такой способ является плохим способом структурирования приложения, подверженным состояниям гонок. Если кто-то держит приставленным к вашей голове ружье, чтобы заставить вас работать таким способом, для правильной работы используйте тщательное блокирование сигналов и интерфейс
sigaction()
.
•
SIGALARM
и системный вызов alarm()
предоставляют низкоуровневый механизм для уведомления о прошествии определенного числа секунд, pause()
приостанавливает процесс, пока не появятся какие-нибудь сигналы, sleep()
использует их для помещения процесса в спящее состояние на заданный период времени: sleep()
и alarm()
не должны использоваться вместе. Сама pause()
создает состояние гонки; вместо этого нужно использовать блокирование сигналов и sigsuspend()
.
• Сигналы управления заданиями реализуют управление заданиями для оболочки. Большую часть времени следует оставлять их с установленными действиями по умолчанию, но полезно понимать, что иногда имеет смысл их перехватывать.
• Перехват
SIGCHLD
позволяет родителю узнать, что делает порожденный им процесс. Использование 'signal(SIGCHLD, SIG_IGN)
' (или sigaction()
с SA_NOCLDWAIT
) вообще игнорирует потомков. Использование sigaction()
с SA_NOCLDSTOP
предоставляет уведомления лишь о завершении. В последнем случае, независимо от того, заблокирован SIGCHLD
или нет, обработчики сигналов для SIGCHLD
должны быть готовы немедленно обработать несколько потомков. Наконец, использование sigaction()
без SA_NOCLDSTOP
с обработчиком сигналов с тремя аргументами дает вам причину получения сигнала.
• После
fork()
положение сигналов в порожденном процессе остается тем же самым, за исключением сброса ожидающих сигналов и установленных интервалов таймера. После exec()
положение несколько более сложно — в сущности, все, что может быть оставлено, остается; для всего остального восстанавливаются значения по умолчанию.
Упражнения
1. Реализуйте
bsd_signal()
с использованием sigaction()
.
2. Если у вас не установлен GNU/Linux, запустите на своей системе
ch10-catchint
. Является ли ваша система традиционной или BSD?
3. Реализуйте функции System V Release 3
sighold()
, sigrelse()
, sigignore()
, sigpause()
и sigset()
, использовав sigaction()
и другие подходящие функции из POSIX API.
4. Потренируйте свои навыки в жонглировании битами. В предположении, что сигнал 0 отсутствует и что имеется не более 31 сигналов, предусмотрите
typedef
для sigset_t
и напишите sigemptyset()
, sigfillset()
, sigaddset()
, sigdelset()
и sigismember()
.
5. Еще немного потренируйте свои навыки жонглирования битами. Повторите предыдущее упражнение, на этот раз предположив, что наибольшим сигналом является 42.
6. Теперь, когда вы сделали предыдущие два упражнения, найдите
sigemptyset()
и др. в своем заголовочном файле
. (Может потребоваться поискать их; они могут быть в #include
файлах, указанных в
.) Являются ли они макросами или функциями?
7. В разделе 10.7 «Сигналы для межпроцессного взаимодействия» мы упомянули, что код изделия должен работать с начальной маской сигналов процесса, добавляя и удаляя блокируемые сигналы в вызове
sigsuspend()
. Перепишите пример, используя для этого соответствующие вызовы.
8. Напишите свою собственную версию команды
kill
. Интерфейс должен быть таким:
kill [-s имя-сигнала] pid ...
Если сигнал не указан, программа должна посылать
SIGTERM
.
9. Как вы думаете, почему в современных оболочках, таких, как Bash и ksh93,
kill
является встроенной командой?
10. (Трудное) Реализуйте
sleep()
, используя alarm()
, signal()
и pause()
. Что случится, если обработчик сигнала для SIGALRM
уже установлен?
11. Поэкспериментируйте с
ch10-reap.c
, изменяя интервал времени, на который засыпает каждый потомок, и организуя достаточное число вызовов sigsuspend()
для сбора сведений о всех потомках.
12. Попробуйте заставить
ch10-reap2.c
испортить информацию в kids
, nkids
и kidsleft
. Теперь добавьте вокруг критического раздела блокирование/разблокирование и посмотрите, есть ли разница.
Данная глава освещает все подробности сигналов, важную, но сложную часть GNU/Linux API.
10.1. Введение
Сигнал является указанием, что случилось какое-то событие, например, попытка сослаться на адрес памяти, который не является частью адресного пространства вашей программы, или когда пользователь нажимает CTRL-C для выхода из программы (называется генерированием прерывания).
Программа может узнать лишь, что определенный сигнал был по крайней мере однажды. Обычно вы не можете сказать, случился ли один и тот же сигнал несколько раз. Вы можете отличить один сигнал от другого и управлять способом реагирования программы на различные сигналы.
Механизмы обработки сигналов развились с течением времени. Как бывает почти со всеми такими механизмами, стандартизованы и доступны как первоначальные, так и более новые API. Однако, из фундаментальных API обработка сигналов обнаруживает, возможно, самые широкие изменения; имеется множество возможностей обработки, чтобы преуспеть в использовании наиболее подходящего API. В результате, возможно, это самая трудная глава в книге. Мы сделаем всевозможное, чтобы сделать изложение более ясным, но если вы проработаете эту главу более тщательно, чем обычно, это поможет.
В отличие от большинства глав в данной книге, наше представление здесь историческое, связанное с освещением развития API, включая API, которые никогда не следует использовать в новом коде. Мы делаем это, потому что это упрощает изложение, делая понятным, почему функция POSIX API
sigaction()10.2. Действия сигналов
Каждый сигнал (вскоре мы представим полный список) имеет связанное с ним действие по умолчанию. POSIX обозначает это как диспозицию (disposition) сигнала. Это то действие, которое ядро осуществляет для процесса, когда поступает определенный сигнал. Действие по умолчанию варьирует:
Завершение
Процесс завершается.
Игнорирование
Сигнал игнорируется. Программа никогда не узнает, что что-то случилось.
Снимок образа процесса
Процесс завершается, и ядро создает файл core (в текущем каталоге процесса), содержащий образ работавшей на момент поступления сигнала программы. Снимок процесса может впоследствии использоваться с отладчиком для исследования состояния программы (см. главу 15 «Отладка»).
По умолчанию системы GNU/Linux создают файлы с именем
core.pidpidcorecorecoreОстановка
Процесс останавливается. Впоследствии он может быть возобновлен. (Если вы использовали управление заданиями оболочки с помощью CTRL-Z,
fgbg
10.3. Стандартные сигналы С: signal()
и raise()
signal()raise()Стандарт ISO С определяет первоначальный API управления сигналами V7 и новый API для посылки сигналов. Вы должны использовать их для программ, которым придется работать на не-POSIX системах, или в случаях, когда предоставляемые ISO С API возможности являются достаточными.
10.3.1. Функция signal()
signal()Действие сигнала изменяется с помощью функции
signal()Функция, которую вы предоставляете для распоряжения сигналом, называется обработчиком сигнала (или просто обработчиком), а установка ее в соответствующем месте осуществляет перехват (catch) сигнала.
Получив эти сведения, давайте перейдем к API. В заголовочном файле
#include /* ISO С */ void (*signal(int signum, void (*func)(int)))(int);Это объявление для функции signal() почти невозможно прочесть. Поэтому справочная страница GNU/Linux signal(2) определяет ее таким способом:
typedef void (*sighandler_t)(int);sighandler_t signal(int signum, sighandler_t handler);Теперь это более вразумительно. Тип
sighandler_tvoidФункция
signal()SIG_DEF,SIG_IGNsignal()signumSIG_ERRsignumТаблица 10.1. Сигналы GNU/Linux
| Имя | Значение | По умолчанию | Источник | Смысл |
|---|---|---|---|---|
|
1 | Term | POSIX | Отсоединение |
|
2 | Term | ISO C | Прерывание |
|
3 | Core | POSIX | Выход |
|
4 | Core | ISO C | Недействительная инструкция |
|
5 | Core | POSIX | Трассировочная ловушка |
|
6 | Core | ISO C | Прекращение |
|
6 | Core | BSD | Ловушка IOT |
|
7 | Core | BSD | Ошибка шины |
|
8 | Core | ISO C | Исключение с плавающей точкой |
|
9 | Term | POSIX | Завершение, неблокируемый |
|
10 | Term | POSIX | Сигнал 1 пользователя |
|
11 | Core | ISO C | Нарушение сегмента |
|
12 | Term | POSIX | Сигнал 2 пользователя |
|
13 | Term | POSIX | Нарушенный канал |
|
14 | Term | POSIX | Аварийные часы |
|
15 | Term | ISO C | Завершение |
|
16 | Term | Linux | Ошибка стека в процессоре (не используется) |
|
17 | Ignr | POSIX | Изменение статуса порожденного процесса |
|
17 | Ignr | System V | То же, что и SIGCHLD (для совместимости) |
|
18 | POSIX | Продолжить при остановке | |
|
19 | Stop | POSIX | Стоп, неблокируемый |
|
20 | Stop | POSIX | Стоп от клавиатуры |
|
21 | Slop | POSIX | Фоновое чтение от tty |
|
22 | Stop | POSIX | Фоновая запись в tty |
|
23 | Ignr | BSD | Срочный сигнал сокета |
|
24 | Core | BSD | Превышение предела процессора |
|
25 | Core | BSD | Превышение предела размера файла |
|
26 | Term | BSD | Виртуальные аварийные часы |
|
27 | Term | BSD | Профилирующие аварийные часы |
|
28 | Ignr | BSD | Изменение размера окна |
|
29 | Term | BSD | Возможен ввод/вывод |
|
29 | Term | System V | Опрашиваемое событие, то же, что и SIGIO (для совместимости) |
|
30 | Term | System V | Повторный запуск из-за сбоя питания |
|
31 | Core | POSIX | Неверный системный вызов |
Обозначения: Core: Завершить процесс и создать снимок образа процесса Ignr: Игнорировать сигнал Stop: Остановить процесс. Term: Завершить процесс.
Более старые версии оболочки Борна (
/bin/shtrapSIGЗАМЕЧАНИЕ. Для некоторых более новых сигналов, от 16 и выше, соответствующие номера сигнала и их имена на различных платформах не обязательно совпадают! Проверьте заголовочные файлы и справочные страницы на своей системе. Табл. 10.1 верна для GNU/Linux
Некоторые системы определяют также и другие сигналы, такие, как
SIGEMTSIGLOSTSIGINFO#ifdef#ifdef SIGLOST/* ...обработать здесь SIGLOST... */#endifЗа исключением
SIGSTKFLT#ifdefСигналы
SIGKILLSIGSTOPЧтобы увидеть список поддерживаемых сигналов, вы можете использовать '
kill -l$ kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR213) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO30) SIGPWR 31) SIGSYS 32) SIGRTMIN 33) SIGRTMIN+134) SIGRTMIN+2 35) SIGRTMIN+3 36) SIGRTMIN+4 37) SIGRTMIN+538) SIGRTMIN+6 39) SIGRTMIN+7 40) SIGRTMIN+8 41) SIGRTMIN+942) SIGRTMIN+10 43) SIGRTMIN+11 44) SIGRTMIN+12 45) SIGRTMIN+1346) SIGRTMIN+14 47) SIGRTMIN+15 48) SIGRTMAX-15 49) SIGRTMAX-1450) SIGRTMAX-13 51) SIGRTMAX-12 52) SIGRTMAX-11 53) SIGRTMAX-1054) SIGRTMAX-9 55) SIGRTMAX-8 56) SIGRTMAX-7 57) SIGRTMAX-658) SIGRTMAX-5 59) SIGRTMAX-4 60) SIGRTMAX-3 61) SIGRTMAX-262) SIGRTMAX-1 63) SIGRTMAXСигналы
SIGRTXXX
10.3.2. Программная отправка сигналов: raise()
raise()Помимо внешнего генерирования, сигнал может быть отправлен непосредственно самой программой с использованием стандартной функции С
raise()#include /* ISO С */ int raise(int sig);Эта функция посылает сигнал
sigПоскольку
raise()10.4. Обработчики сигналов в действии
Множество осложнений и отклонений обнаруживается после установки на место обработчика, после его вызова и впоследствии возвращения.
10.4.1. Традиционные системы
После помещения на место обработчика сигнала ваша программа развивается своим путем. Интересные вещи возникают лишь с появлением сигнала (например, пользователь нажал CTRL-C для прерывания вашей программы, или был сделан вызов
raise()По получении сигнала ядро останавливает процесс, где бы он ни был. Затем оно имитирует вызов процедуры обработчика сигнала, передавая ему номер сигнала в качестве ее единственного аргумента. Ядро устраивает все таким образом, что нормальный возврат из функции обработчика сигнала (либо посредством
returnЧто происходит после обработки сигнала, когда тот же самый сигнал появится в следующий раз снова? Остается ли обработчик на том же месте? Или же он сбрасывается, и для сигнала используется действие по умолчанию? Ответ, по историческим причинам, «зависит от». В частности, стандарт С оставляет это на усмотрение реализации.
На практике V7 и традиционные системы System V, такие, как Solaris, устанавливают для сигнала действие по умолчанию.
Давайте рассмотрим простой обработчик сигнала в действии под Solaris. Следующая программа,
ch10-catchint.cSIGINT1 /* ch10-catchint.c - перехват SIGINT, по крайней мере, однажды. */23 #include 4 #include 5 #include 67 /* handler --- простой обработчик сигнала. */89 void handler(int signum)10 {11 char buf[200], *cp;12 int offset;1314 /* Пройти через это испытание , чтобы избежать fprintf(). */15 strcpy(buf, "handler: caught signal ");16 cp = buf + strlen(buf); /* cp указывает на завершающий '\0' */17 if (signum > 100) /* маловероятно */18 offset = 3;19 else if (signum > 10)20 offset = 2;21 else22 offset = 1;23 cp += offset;2425 *cp-- = '\0'; /* завершить строку */26 while (signum >0) { /* work backwards, filling in digits */27 *cp-- = (signum % 10) + '0';28 signum /= 10;29 }30 strcat(buf, "\n");31 (void)write(2, buf, strlen(buf));32 }3334 /* main --- установить обработку сигнала и войти в бесконечный цикл */3536 int main(void)37 {38 (void)signal(SIGINT, handler);3940 for(;;)41 pause(); /* ждать сигнал, см. далее в главе */4243 return 0;44 }Строки 9–22 определяют функцию обработки сигнала (остроумно названную
handler()fprintf()Функция
main()$ ssh solaris.example.com /* Зарегистрироваться на доступной системе Solaris */Last login: Fri Sep 19 04:33:25 2003 from 4.3.2.1.Sun Microsystems Inc. SunOS 5.9 Generic May 2002$ gcc ch10-catchint.c /* Откомпилировать программу */$ a.out /* Запустить ее */^C handler: caught signal 2 /* Набрать ^C, вызывается обработчик */^C /* Попробовать снова, но на этот раз... */$ /* Программа завершается */Поскольку V7 и другие традиционные системы восстанавливают действие сигнала по умолчанию, поэтому когда вы хотите снова получить сигнал в будущем, функция обработчика должна немедленно переустановить саму себя:
void handler(int signum) { char buf[200], *cp; int offset; (void)signal(signum, handler); /* переустановить обработчик */ /* ...оставшаяся часть функции как прежде... */}10.4.2. BSD и GNU/Linux
BSD 4.2 изменила способ работы
signal()$ ch10-catchint /* Запустить программу */handler: caught signal 2 /* Набираем ^C, вызывается обработчик */handler: caught signal 2 /* И снова... */handler: caught signal 2 /* И снова! */handler: caught signal 2 /* Помогите! */handler: caught signal 2 /* Как нам это остановить?! */Quit (core dumped) /* ^\, генерирует SIGQUIT. Bay */На системе BSD или GNU/Linux обработчик сигнала не должен дополнительно использовать '
signal(signum, handler)В действительности, POSIX предоставляет функцию
bsd_signal()signal()#include /* XSI, устаревает */ void (*bsd_signal(int sig, void (*func)(int)))(int);Это устраняет проблемы переносимости. Если вы знаете, что ваша программа будет работать лишь на системах POSIX, вы можете воспользоваться
bsd_signal()signal()Одно предостережение — эта функция также помечена как «устаревающая», что означает возможность отказа от нее в будущем стандарте. На практике, даже если от нее откажутся, поставщики скорее всего долгое время будут ее поддерживать. (Как мы увидим, функция API POSIX
sigaction()10.4.3. Игнорирование сигналов
Более практично, когда вызывается обработчик сигнала, это означает, что программа должна завершиться и выйти. Было бы раздражающим, если бы большинство программ по получении
SIGINTНапример, рассмотрите программу
sortsortSIGINTsortsort.c/* Обработка прерываний и отсоединений. Упрощена для представления */static void sighandler(int sig) { signal(sig, SIG_IGN); /* Отныне этот сигнал игнорировать */ cleanup(); /* Очистка после себя */ signal(sig, SIG_DFL); /* Восстановление действия по умолчанию */ raise(sig); /* Повторно отправить сигнал */}Установка действия
SIG_IGNSIGINTcleanup()SIG_DFLraise()sort.c
10.4.4. Системные вызовы, допускающие повторный запуск
Значение
EINTR
для errno
(см. раздел 4.3 «Определение ошибок») указывает, что системный вызов был прерван. Хотя с этим значением ошибки может завершаться большое количество системных вызовов, двумя наиболее значительными являются read()
и write()
. Рассмотрите следующий код:
void handler(int signal) { /* обработка сигналов */ }
int main(int argc, char **argv) {
signal(SIGINT, handler);
...
while ((count = read(fd, buf, sizeof buf)) > 0) {
/* Обработка буфера */
}
if (count == 0)
/* конец файла, очистка и т.п. */
else if (count == -1)
/* ошибка */
...
}
Предположим, что система успешно прочла (и заполнила) часть буфера, когда возник
SIGINT
. Системный вызов read()
еще не вернулся из ядра в программу, но ядро решает, что оно может доставить сигнал. Вызывается handler()
, запускается и возвращается в середину read()
. Что возвратит read()
?
В былые времена (V7, более ранние системы System V)
read()
возвратила бы -1 и установила бы errno
равным EINTR
. Не было способа сообщить, что данные были переданы. В данном случае V7 и System V действуют, как если бы ничего не случилось: не было перемещений данных в и из буфера пользователя, и смещение файла не было изменено. BSD 4.2 изменила это. Были два случая:
Медленные устройства
«Медленное устройство» является в сущности терминалом или почти всяким другим устройством, кроме обычного файла. В этом случае
read()
могла завершиться с ошибкой EINTR
, лишь если не было передано никаких данных, когда появился сигнал. В противном случае системный вызов был бы запущен повторно, и read()
возвратилась бы нормально.
Обычные файлы
Системный вызов был бы запущен повторно В этом случае
read()
вернулась бы нормально; возвращенное значение могло быть либо числом запрошенных байтов, либо числом действительно прочитанных байтов (как в случае чтения вблизи конца файла).
Поведение BSD несомненно полезно; вы всегда можете сказать, сколько данных было прочитано.
Поведение POSIX сходно, но не идентично первоначальному поведению BSD. POSIX указывает, что
read()
[108] завершается с ошибкой EINTR
лишь в случае появления сигнала до начала перемещения данных. Хотя POSIX ничего не говорит о «медленных устройствах», на практике это условие проявляется именно на них.
В противном случае, если сигнал прерывает частично выполненную
read()
, возвращенное значение является числом уже прочитанных байтов. По этой причине (а также для возможности обработки коротких файлов) всегда следует проверять возвращаемое read()
значение и никогда не предполагать, что прочитано все запрошенное количество байтов. (Функция POSIX API sigaction()
, описанная позже, позволяет при желании получить поведение повторно вызываемых системных вызовов BSD.)
10.4.4.1. Пример: GNU Coreutils safe_read()
и safe_write()
Для обработки случая EINTR в традиционных системах GNU Coreutils использует две функции,
safe_read()
и safe_write()
. Код несколько запутан из-за того, что один и тот же файл за счет включения #include и макросов реализует обе функции. Из файла lib/safe-read.c
в дистрибутиве Coreutils:
1 /* Интерфейс read и write для .повторных запусков после прерываний.
2 Copyright (С) 1993, 1994, 1998, 2002 Free Software Foundation, Inc.
/* ... куча шаблонного материала опущена... */
56
57 #ifdef SAFE_WRITE
58 # include "safe-write.h"
59 # define safe_rw safe_write /* Создание safe_write() */
60 # define rw write /* Использование системного вызова write() */
61 #else
62 # include "safe-read.h"
63 # define safe_rw safe_read /* Создание safe_read() */
64 # define rw read /* Использование системного вызова read() */
65 # undef const
66 # define const /* пусто */
67 #endif
68
69 /* Прочесть (записать) вплоть до COUNT байтов в BUF из(в) дескриптора FD, повторно запуская вызов при
70 прерывании. Вернуть число действительно прочитанных (записанных) байтов, 0 для EOF
71 или в случае ошибки SAFE_READ_ERROR(SAFE_WRITE_ERROR). */
72 size_t
73 safe_rw(int fd, void const *buf, size_t count)
74 {
75 ssize_t result;
76
77 /* POSIX ограничивает COUNT значением SSIZE_MAX, но мы еще больше ограничиваем его, требуя,
78 чтобы COUNT <= INT_MAX, для избежания ошибки в Tru64 5.1.
79 При уменьшении COUNT сохраняйте указатель файла выровненным по размеру блока.
80 Обратите внимание, что read (write) может быть успешным в любом случае, даже если прочитано (записано)
81 менее COUNT байтов, поэтому вызывающий должен быть готов обработать
82 частичные результаты. */
83 if (count > INT_MAX)
84 count = INT_MAX & -8191;
85
86 do
87 {
88 result = rw(fd, buf, count);
89 }
90 while (result < 0 && IS_EINTR(errno));
91
92 return (size_t) result;
93 }
Строки 57–67 обрабатывают определения, создавая соответствующим образом
safe_read()
и safe_write()
(см. ниже safe_write.c
).
Строки 77–84 указывают на разновидность осложнений, возникающих при чтении. Здесь один особый вариант Unix не может обработать значения, превышающие
INT_MAX
, поэтому строки 83–84 выполняют сразу две операции: уменьшают значение числа, чтобы оно не превышало INT_MAX
, и сохраняют его кратным 8192. Последняя операция служит эффективности дисковых операций: выполнение ввода/вывода с кратным основному размеру дискового блока объемом данных более эффективно, чем со случайными размерами данных. Как отмечено в комментарии, код сохраняет семантику read()
и write()
, где возвращенное число байтов может быть меньше затребованного.
Обратите внимание, что параметр
count
может и в самом деле быть больше INT_MAX
, поскольку count представляет тип size_t
, который является беззнаковым (unsigned). INT_MAX
является чистым int
, который на всех современных системах является знаковым.
Строки 86–90 представляют действительный цикл, повторно осуществляющий операцию, пока она завершается ошибкой
EINTR
. Макрос IS_EINTR()
не показан, но он обрабатывает случай в системах, на которых EINTR
не определен. (Должен быть по крайней мере один такой случай, иначе код не будет возиться с установкой макроса; возможно, это было сделано для эмуляции Unix или POSIX в не-Unix системе.) Вот safe_write.c
:
1 /* Интерфейс write для повторного запуска после прерываний.
2 Copyright (С) 2002 Free Software Foundation, Inc.
/* ...куча шаблонного материала опущена... */
17
18 #define SAFE_WRITE
19 #include "safe-read.с"
В строке 18
#define
определяет SAFE_WRITE
; это связано со строками 57–60 в safe_read.с
.
10.4.4.2. Только GLIBC: TEMP_FAILURE_RETRY()
Файл GLIBC определяет макрос TEMP_FAILURE_RETRY(), который вы можете использовать для инкапсулирования любого системного вызова, который может при неудачном вызове установить errno в EINTR. Его «объявление» следующее:
#include /* GLIBC */
long int TEMP_FAILURE_RETRY(expression);
Вот определение макроса:
/* Оценить EXPRESSION и повторять, пока оно возвращает -1 с 'errno',
установленным в EINTR. */
# define TEMP_FAILURE_RETRY(expression) \
(__extension__ \
({ long int __result; \
do __result = (long int)(expression); \
while (__result == -1L && errno == EINTR); \
__result; }))
Макрос использует расширение GCC к языку С (как обозначено ключевым словом
__extension__
), которое допускает заключенным в фигурные скобки внутри обычных скобок выражениям возвращать значение, действуя таким образом подобно простому выражению.
Используя этот макрос, мы могли бы переписать
safe_read()
следующим образом:
size_t safe_read(int fd, void const *buf, size_t count) {
ssize_t result;
/* Ограничить count, как в ранее приведенном комментарии. */
if (count > INT_MAX)
count = INT_MAX & ~8191;
result = TEMP_FAILURE_RETRY(read(fd, buf, count));
return (size_t)result;
}
Значение
EINTRerrnoread()write()void handler(int signal) { /* обработка сигналов */ }int main(int argc, char **argv) { signal(SIGINT, handler); ... while ((count = read(fd, buf, sizeof buf)) > 0) { /* Обработка буфера */ } if (count == 0) /* конец файла, очистка и т.п. */ else if (count == -1) /* ошибка */ ...}Предположим, что система успешно прочла (и заполнила) часть буфера, когда возник
SIGINTread()handler()read()read()В былые времена (V7, более ранние системы System V)
read()errnoEINTRМедленные устройства
«Медленное устройство» является в сущности терминалом или почти всяким другим устройством, кроме обычного файла. В этом случае
read()EINTRread()Обычные файлы
Системный вызов был бы запущен повторно В этом случае
read()Поведение BSD несомненно полезно; вы всегда можете сказать, сколько данных было прочитано.
Поведение POSIX сходно, но не идентично первоначальному поведению BSD. POSIX указывает, что
read()EINTRВ противном случае, если сигнал прерывает частично выполненную
read()read()sigaction()
10.4.4.1. Пример: GNU Coreutils safe_read()
и safe_write()
safe_read()safe_write()Для обработки случая EINTR в традиционных системах GNU Coreutils использует две функции,
safe_read()safe_write()lib/safe-read.c1 /* Интерфейс read и write для .повторных запусков после прерываний.2 Copyright (С) 1993, 1994, 1998, 2002 Free Software Foundation, Inc. /* ... куча шаблонного материала опущена... */5657 #ifdef SAFE_WRITE58 # include "safe-write.h"59 # define safe_rw safe_write /* Создание safe_write() */60 # define rw write /* Использование системного вызова write() */61 #else62 # include "safe-read.h"63 # define safe_rw safe_read /* Создание safe_read() */64 # define rw read /* Использование системного вызова read() */65 # undef const66 # define const /* пусто */67 #endif6869 /* Прочесть (записать) вплоть до COUNT байтов в BUF из(в) дескриптора FD, повторно запуская вызов при70 прерывании. Вернуть число действительно прочитанных (записанных) байтов, 0 для EOF71 или в случае ошибки SAFE_READ_ERROR(SAFE_WRITE_ERROR). */72 size_t73 safe_rw(int fd, void const *buf, size_t count)74 {75 ssize_t result;7677 /* POSIX ограничивает COUNT значением SSIZE_MAX, но мы еще больше ограничиваем его, требуя,78 чтобы COUNT <= INT_MAX, для избежания ошибки в Tru64 5.1.79 При уменьшении COUNT сохраняйте указатель файла выровненным по размеру блока.80 Обратите внимание, что read (write) может быть успешным в любом случае, даже если прочитано (записано)81 менее COUNT байтов, поэтому вызывающий должен быть готов обработать82 частичные результаты. */83 if (count > INT_MAX)84 count = INT_MAX & -8191;8586 do87 {88 result = rw(fd, buf, count);89 }90 while (result < 0 && IS_EINTR(errno));9192 return (size_t) result;93 }Строки 57–67 обрабатывают определения, создавая соответствующим образом
safe_read()safe_write()safe_write.cСтроки 77–84 указывают на разновидность осложнений, возникающих при чтении. Здесь один особый вариант Unix не может обработать значения, превышающие
INT_MAXINT_MAXread()write()Обратите внимание, что параметр
countINT_MAXsize_tINT_MAXintСтроки 86–90 представляют действительный цикл, повторно осуществляющий операцию, пока она завершается ошибкой
EINTRIS_EINTR()EINTRsafe_write.c1 /* Интерфейс write для повторного запуска после прерываний.2 Copyright (С) 2002 Free Software Foundation, Inc. /* ...куча шаблонного материала опущена... */1718 #define SAFE_WRITE19 #include "safe-read.с"В строке 18
#defineSAFE_WRITEsafe_read.с
10.4.4.2. Только GLIBC: TEMP_FAILURE_RETRY()
TEMP_FAILURE_RETRY()Файл
#include /* GLIBC */ long int TEMP_FAILURE_RETRY(expression);Вот определение макроса:
/* Оценить EXPRESSION и повторять, пока оно возвращает -1 с 'errno', установленным в EINTR. */# define TEMP_FAILURE_RETRY(expression) \ (__extension__ \ ({ long int __result; \ do __result = (long int)(expression); \ while (__result == -1L && errno == EINTR); \ __result; }))Макрос использует расширение GCC к языку С (как обозначено ключевым словом
__extension__Используя этот макрос, мы могли бы переписать
safe_read()size_t safe_read(int fd, void const *buf, size_t count) { ssize_t result; /* Ограничить count, как в ранее приведенном комментарии. */ if (count > INT_MAX) count = INT_MAX & ~8191; result = TEMP_FAILURE_RETRY(read(fd, buf, count)); return (size_t)result;}
10.4.5. Состояния гонок и sig_atomic_t
(ISO C)
sig_atomic_tПока обработка одного сигнала за раз выглядит просто: установка обработчика сигнала в
main()SIG_IGNНо что произойдет, если возникнут два идентичных сигнала, один за другим? В частности, что, если ваша система восстановит действие по умолчанию для вашего сигнала, а второй сигнал появится после вызова обработчика, но до того, как он себя восстановит?
Или предположим, что вы используете
bsd_signal()Оба случая относятся к состоянию гонки. Одним решением для этих проблем является как можно большее упрощение обработчиков сигналов. Это можно сделать, создав флаговые переменные, указывающие на появление сигнала. Обработчик сигнала устанавливает переменную в true и возвращается. Затем основная логика проверяет флаговую переменную в стратегических местах:
int sig_int_flag = 0; /* обработчик сигнала устанавливает в true */void int_handler(int signum) { sig_int_flag = 1;}int main(int argc, char **argv) { bsd_signal(SIGINT, int_handler); /* ...программа продолжается... */ if (sig_int_flag) { /* возник SIGINT, обработать его */ } /* ...оставшаяся логика... */}(Обратите внимание, что эта стратегия уменьшает окно уязвимости, но не устраняет его).
Стандарт С вводит специальный тип —
sig_atomic_tintsig_atomic_tНаличие особого типа является лишь частью истории. Переменные
sig_atomic_tvolatilevolatile sig_atomic_t sig_int_flag = 0; /* обработчик сигнала устанавливает в true *//* ...оставшаяся часть кода как раньше... */Ключевое слово
volatileСтруктурирование приложения исключительно вокруг переменных
sig_atomic_t10.4.6. Дополнительные предостережения
Стандарт POSIX предусматривает для обработчиков сигналов несколько предостережений:
• Что случается, когда возвращаются обработчики для
SIGFPESIGILLSIGSEGV• Если обработчик был вызван в результате вызова
abort()raise()kill()raise()abort()abort()kill()sigaction()• Обработчики сигналов могут вызвать лишь функции из табл. 10.2. В частности, они должны избегать функций
Список в табл. 10.2 происходит из раздела 2.4 тома System Interfaces (Системные интерфейсы) стандарта POSIX 2001. Многие из этих функций относятся к сложному API и больше не рассматриваются в данной книге.
Таблица 10.2. Функции, которые могут быть вызваны из обработчика сигнала
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
10.4.7. Наша история до настоящего времени, эпизод 1
Сигналы являются сложной темой, и она становится еще более сбивающей с толку. Поэтому давайте на время сделаем остановку, сделаем шаг назад и подведем итог обсужденному до сих пор:
• Сигналы являются указанием того, что произошло некоторое внешнее событие.
•
raise()•
signal()• Когда сигнал перехватывается, вызывается функция-обработчик. Вот где сложность начинает поднимать свою безобразную голову:
• ISO С не определяет, восстанавливается ли диспозиция сигнала по умолчанию до вызова обработчика или она остается на месте. Первое является поведением V7 и современных систем System V, таких, как Solaris. Последнее является поведением BSD, используемым также в GNU/Linux. (Для форсирования поведения BSD может использоваться функция POSIX
bsd_signal()• То, что случается при прерывании сигналом системного вызова, также различается в традиционной и BSD линейках. Традиционные системы возвращают -1 с errno, установленным в
EINTRTEMP_FAILURE_RETRY()errnoEINTRPOSIX требует, чтобы частично выполненный системный вызов возвращал успешное завершение, указав, сколько работы было выполнено. Системный вызов, который еще не начал выполняться, вызывается повторно.
• Механизм
signal()sig_atomic_t• Применяется ряд дополнительных предостережений, и в частности, из обработчика сигнала безопасно может вызываться лишь часть стандартных библиотечных функций.
Несмотря на эти проблемы интерфейса
signal()
10.5. API сигналов System V Release 3: sigset()
и др.
sigset()BSD 4.0 (примерно с 1980 г.) ввел дополнительные функции API для предоставления «надежных» сигналов.[109] В частности, стало возможным блокировать сигналы. Другими словами, программа могла сообщить ядру: «Зависни на этих конкретных сигналах в течении следующего небольшого промежутка времени, затем доставь их мне, когда я буду готов их принять». Большим преимуществом является то, что эта особенность упрощает обработчики сигналов, которые автоматически запускаются со своим заблокированным сигналом (чтобы избежать проблемы одновременной обработки двух сигналов) и, возможно, также и с другими заблокированными сигналами.
System V Release 3 (примерно с 1984 г.) приняла эти API и популяризовала их, в большинстве связанных с Unix документации и книгах вы, возможно, увидите, что на эти API ссылаются, как ведущие начало от System V Release 3. Эти функции следующие:
#include /* XSI */ int sighold(int sig); /* Добавить sig к маске сигналов процесса */int sigrelse(int sig); /* Удалить sig из маски сигналов процесса */int sigignore(int sig); /* Сокращение для sigset(sig, SIG_IGN) */int sigpause(int sig); /* Приостановить процесс, позволить появиться sig */void (*sigset(int sig, void (*disp)(int)))(int); /* sighandler_t sigset(int sig, sighandler_t disp); */Стандарт POSIX для этих функций описывает их поведение в терминах маски сигналов процесса. Маска сигналов процесса отслеживает, какие сигналы (если они вообще есть) процесс заблокировал в настоящее время. Более подробно это описывается в разделе 10.6.2 «Наборы сигналов:
sigset_tint sighold(int sig)Добавляет
sigint sigrelse(int sig)Удаляет
sigint sigignore(int sig)Игнорирует
sigint sigpause(int sig)Удаляет
sigsighandler_t sigset(int sig, sighandler_t disp)Это замена для signal(). (Здесь мы использовали обозначение из справочной страницы GNU/Linux, чтобы упростить восприятие объявления функции.)
Для
sigset()handlerSIG_DFLSIG_IGNsignal()SIG_HOLDsigКогда для установки обработчика сигнала используется
sigset()sighold()sigrelse()ЗАМЕЧАНИЕ. POSIX стандартизует эти API, поскольку главной целью POSIX является формализация существующей практики, где это возможно. Однако, функции
sigaction()sigaction()10.6. Сигналы POSIX
API POSIX основан на API
sigvec()sigaction()sigvec()sigaction()sigvec()sigaction()10.6.1. Обнажение проблемы
Что неладно с API System V Release 3? В конце концов, они предоставляют блокирование сигналов, так, что сигналы не теряются, и любой данный сигнал может быть надежно обработан.
Ответ в том, что этот API работает лишь с одним сигналом в одно и то же время. Программы обычно обрабатывают больше одного сигнала. И когда вы находитесь в середине процесса обработки одного сигнала, вы не хотите беспокоиться по поводу обработки еще и второго. (Предположим, вы только что начали отвечать по офисному телефону, когда зазвонил ваш мобильный телефон: вы бы предпочли, чтобы телефонная система ответила вызывающему, что в данный момент вы находитесь на другой линии и что скоро освободитесь, вместо того, чтобы проделывать все это самому.)
С API
sigset()sighold()Решением является обеспечение возможности автоматической работы с группами сигналов, т.е. с помощью одного системного вызова. Вы достигаете этого, работая с наборами сигналов и маской сигналов процесса.
10.6.2. Наборы сигналов: sigset_t
и связанные функции
sigset_tМаска сигналов процесса является списком сигналов, которые процесс в настоящее время заблокировал. Сила POSIX API в том, что маской сигналов процесса можно манипулировать атомарно, как единым целым.
Маска сигналов процесса программно представляется с помощью набора сигналов. Это тип
sigset_t/* Непосредственное манипулирование маской сигналов. НЕ ДЕЛАЙТЕ ЭТОГО! */int mask = (1 << SIGHUP) | (1 << SIGINT); /* битовая маска для SIGHUP и SIGINT */Однако, поскольку в системе может быть больше сигналов, чем может содержаться в одной
intlong#include /* POSIX */ int sigemptyset(sigset_t *set);int sigfillset(sigset_t *set);int sigaddset(sigset_t *set, int signum);int sigdelset(sigset_t *set, int signum);int sigismember(const sigset_t *set, int signum);Эти функции следующие:
int sigemptyset(sigset_t *set)Освобождает набор сигналов. По возвращении
*setint sigfillset(sigset_t *set)Полностью заполняет набор сигналов. По возвращении
*setint sigaddset(sigset_t *set, int signum)Добавляет
signum*setint sigdelset(sigset_t *set, int signum)Удаляет
signum*setint sigismember(const sigset_t *set, int signum)Возвращает true/false, если
signum*setПеред выполнением с переменной
sigset_tsigemptyset()sigfillset()
10.6.3. Управление маской сигналов: sigprocmask()
и др.
sigprocmask()Маска сигналов процесса вначале пуста - заблокированных сигналов нет. (Это упрощение; см. раздел 10.9 «Сигналы, передающиеся через
fork()exec()#include /* POSIX */ int sigprocmask(int how, const sigset_t *set, sigset_t *oldset);int sigpending(sigset_t *set);int sigsuspend(const sigset_t *set);Функции следующие:
int sigprocmask(int how, const sigset_t *set, sigset_t *oldset)Если
oldsetNULL*oldsetsethowSIG_BLOCK *set*setSIG_UNBLOCK *set*setSIG_SETMASK *setЕсли
setNULLoldsethowint sigpending(sigset_t *set)Эта функция позволяет увидеть, какие сигналы ожидают решения; т.е.
*setint sigsuspend(const sigset_t *set)Эта функция временно заменяет маску сигналов процесса содержимым
*set*set
10.6.4. Перехват сигналов: sigaction()
sigaction()Наконец мы готовы взглянуть на функцию
sigaction()#include /* POSIX */ int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);Аргументы следующие:
int signumИнтересующий сигнал, как в случае с другими функциями обработки сигналов.
const struct sigaction *actОпределение нового обработчика для сигнала
signumstruct sigaction *oldactОпределение текущего обработчика. Если не
NULL*act*oldact*actNULL*oldactТаким образом,
sigaction()struct sigaction/* ПРИМЕЧАНИЕ: Порядок в структуре может варьировать. Могут быть также и другие поля! */struct sigaction { sigset_t sa_mask; /* Дополнительные сигналы для блокирования */ int sa_flags; /* Контролирует поведение */ void (*sa_handler)(int); /* Может образовать объединение с sa_sigaction */ void (*sa_sigaction)(int, siginfo_t*, void*); /* Может образовать объединение с sa_handler */}Поля следующие:
sigset_t sa_maskНабор дополнительных сигналов для блокирования при запуске функции обработчика. Таким образом, когда вызывается обработчик, общий набор заблокированных сигналов является объединением сигналов в маске процесса, сигналов в
act->maskSA_NODEFERsignumint sa_flagsФлаги, контролирующие обработку сигнала ядром. См. обсуждение далее.
void (*sa_handler)(int)Указатель на «традиционную» функцию обработчика. У нее такой же прототип (возвращаемый тип и список параметров), как у функции обработчика для
signal()bsd_signal()sigset()void (*sa_sigaction)(int, siginfo_t*, void*)Указатель на функцию обработчика «нового стиля». Функция принимает три аргумента, которые вскоре будут описаны.
Которая из функций
act->sa_handleract->sa_sigactionSA_SIGINFOact->sa_flagsact->sa_sigactionact->sa_handlerunionstruct sigactionПоле
sa_flagsТаблица 10.3. Значения флагов для
sa_flags| Флаг | Значение |
|---|---|
|
Этот флаг имеет смысл лишь для |
|
Этот флаг имеет смысл лишь для |
|
Обычно данный сигнал блокируется, когда вызывается обработчик сигнала. Когда установлен один из этих флагов, данный сигнал не блокируется при запуске обработчика |
|
Альтернативное имя для |
|
Обработчик сигнала принимает три аргумента. Как упоминалось, при данном установленном флаге должно использоваться поле |
|
Это продвинутая возможность. Обработчики сигналов могут вызываться с использованием предоставленной пользователем памяти в качестве «альтернативного стека сигнала». Эта память даётся ядру для подобного использования посредством |
|
Этот флаг обеспечивает поведение V7: после вызова обработчика восстанавливается действие сигнала по умолчанию. Официальным именем POSIX флага (которое следует использовать) является |
|
Альтернативное имя для |
|
Этот флаг предоставляет семантику BSD: системные вызовы, которые могут завершиться с ошибкой |
Когда в
act->sa_flagsSA_SIGINFOact->sa_sigactionvoid action_handler(int sig, siginfo_t *info, void *context) { /* Здесь тело обработчика */}Структура
siginfo/* Определение POSIX 2001. Действительное содержание может на разных системах быть разным. */typedef struct { int si_signo; /* номер сигнала */ int si_errno; /* значение при ошибке */ int si_code; /* код сигнала; см. текст */ pid_t si_pid; /* ID процесса, пославшего сигнал */ uid_t si_uid; /* настоящий UID посылающего процесса */ void *si_addr; /* адрес вызвавшей ошибку инструкции */ int si_status; /* значение завершения, может включать death-by-signal */ long si_band; /* связывающее событие для SIGPOLL/SIGIO */ union sigval si_value; /* значение сигнала (расширенное) */} siginfo_t;Поля
si_signosi_codesi_valuesiginfo_tПочти все поля предназначены для расширенного использования. Все подробности содержатся в стандарте POSIX и справочной странице sigaction(2). Однако, мы можем описать простое использование поля
si_codeДля
SIGBUSSIGCHLDSIGFPESIGILLSIGPOLLSIGSEGVSIGTRAPSIGCHLDsi_codeТаблица 10.4. Значения происхождения сигнала для
si_code| Значение | Только GLIBC | Смысл |
|---|---|---|
|
Асинхронный ввод/вывод завершен (расширенный). | |
|
√ | Сигнал послан ядром. |
|
Состояние очереди сообщений изменилось (расширенный.) | |
|
Сигнал послан из |
|
|
√ | |
|
Время таймера истекло | |
|
Сигнал послан функцией |
В особенности полезно значение
SI_USERraise()kill()raise()kill()Третий аргумент обработчика сигнала с тремя аргументами,
void *contexНаконец, чтобы увидеть
sigaction()sort.c2074 static void2075 sighandler(int sig)2076 {2077 #ifndef SA_NOCLDSTOP /* В системе старого стиля... */2078 signal(sig, SIG_IGN); /* - для игнорирования sig используйте signal()*/2079 #endif - /* В противном случае sig автоматически блокируется */20802081 cleanup(); /* Запуск кода очистки */20822083 #ifdef SA_NOCLDSTOP /* В системе в стиле POSIX... */2084 {2085 struct sigaction sigact;20862087 sigact.sa_handler = SIG_DFL; /* - Установить действие по умолчанию */2088 sigemptyset(&sigact.sa_mask); /* - Нет дополнительных сигналов для блокирования */2089 sigact.sa_flags = 0; /* - Специальные действия не предпринимаются */2090 sigaction(sig, &sigact, NULL); /* - Поместить на место */2091 }2092 #else /* На системе в старом стиле... */2093 signal(sig, SIG_DFL); /* - Установить действие по умолчанию */2094 #endif20952096 raise(sig); /* Повторно послать сигнал */2097 }Вот код в
main()2214 #ifdef SA_NOCLDSTOP /* На системе POSIX... */2215 {2216 unsigned i;2217 sigemptyset(&caught_signals);2218 for (i = 0; i < nsigs; i++) /* - Блокировать все сигналы */2219 sigaddset(&caught_signals, sigs[i]);2220 newact.sa_handler = sighandler; /* - Функция обработки сигнала */2221 newact.sa_mask = caught_signals; /* - Установить для обработчика маску сигналов процесса */2222 newact.sa_flags =0; /* - Особых флагов нет */2223 }2224 #endif22252226 {2227 unsigned i;2228 for (i = 0; i < nsigs; i++) /* Для всех сигналов... */2229 {2230 int sig = sigs[i];2231 #ifdef SA_NOCLDSTOP2232 sigaction(sig, NULL, &oldact); /* - Получить старый обработчик */2233 if (oldact.sa_handler != SIG_IGN) /* - Если этот сигнал не игнорируется */2234 sigaction(sig, &newact, NULL); /* - Установить наш обработчик */2235 #else2236 if (signal(sig, SIG_IGN) != SIG_IGN)2237 signal(sig, sighandler); /* - Та же логика со старым API */2238 #endif2239 }2240 }Мы заметили, что строки 2216–2219 и 2221 могут быть замещены одним вызовом:
sigfillset(&newact.sa_mask)Мы не знаем, почему код написан именно таким способом.
Интерес представляют также строки 2233–2234 и 2236–2237, которые показывают правильный способ проверки того, игнорируется ли сигнал, и для установки обработчика лишь в том случае, если сигнал не игнорируется.
ЗАМЕЧАНИЕ. Функции API
sigaction()signal()signal()struct sigactionsignal()
10.6.5. Извлечение ожидающих сигналов: sigpending()
sigpending()Описанный ранее системный вызов
sigpending()#include /* POSIX */ int sigpending(sigset_t *set);Помимо разблокировки ожидающих сигналов, чтобы они могли быть доставлены, вы можете решить их игнорировать. Установка действия сигнала
SIG_IGNSIG_DFL
10.6.6. Создание возможности для прерывания функций: siginterrupt()
siginterrupt()Чтобы сделать определенную функцию прерываемой или повторно запускаемой в зависимости от значения второго аргумента, в качестве удобного средства может использоваться функция
siginterrupt()#include /* XSI */ int siginterrupt(int sig, int flag);В соответствии со стандартом POSIX поведение
siginterrupt()int siginterrupt(int sig, int flag) { int ret; struct sigaction act; (void)sigaction(sig, NULL, &act); /* Получить старые установки */ if (flag) /* Если flag равен true... */ act.sa_flags &= ~SA_RESTART; /* Запретить повторный запуск */ else /* В противном случае... */ act.sa_flags |= SA_RESTART; /* Разрешить повторный запуск */ ret = sigaction(sig, &act, NULL); /* Поместить новые установки на место */ return ret; /* Вернуть результат */}В случае успеха возвращаемое значение равно 0 и -1 при ошибке.
10.6.7. Передача сигналов: kill()
и killpg()
kill()killpg()Традиционная функция Unix для передачи сигналов называется
kill()killpg()#include /* POSIX */ #include int kill(pid_t pid, int sig);int killpg(int pgrp, int sig); /* XSI */Аргумент
sigkill()errnoПравила для значения
pidpid > 0 pidpid = 0 pid = -1 initpid < -1 pidkillpg()Значение
pidkill()waitpid()wait()waitpid()Стандартная функция С
raise()int raise(int sig) { return kill(getpid(), sig);}Комитет по стандартизации С выбрал имя
raise()kill()killpg()pgrpkill(-pgrp, sig)pgrpkill()Как вы могли представить, нельзя послать сигнал произвольному процессу (если вы не являетесь суперпользователем,
rootОднако
SIGCONT10.6.8. Наша история до настоящего времени, эпизод II
System V Release 3 API был предназначен для исправления различных проблем, представленных первоначальным API сигналов V7. В частности, важной дополнительной концепцией является понятие о блокировке сигналов.
Однако, этот API оказался недостаточным, поскольку он работал лишь с одним сигналом за раз, оставляя множество широко открытых окон, через которые могли поступать нежелательные сигналы. POSIX API, работая атомарно с множеством сигналов (маской сигналов процесса, программно представленной типом
sigset_tПервый набор функций, который мы исследовали, манипулирует значениями
sigset_tsigfillset()sigemptyset()sigaddset()sigdelset()sigismember()Следующий набор работает с маской сигналов процесса:
sigprocmask()sigpending()sigsuspend()Функция POSIX API
sigaction()• обратную совместимость:
SA_RESETHANDSA_RESTARTsa_flags• выбор, блокировать также полученный сигнал или нет:
SA_NODEFER_flags• возможность иметь два различных вида обработчиков сигналов: с одним или с тремя аргументами;
• выбор поведения для управления
SIGCHLDSA_NOCLDSTOPSA_NOCLDWAITsa_flagsФункция
siginterrupt()Наконец, для посылки сигналов не только текущему, но также и другим процессам могут использоваться
kill()killpg()10.7. Сигналы для межпроцессного взаимодействия
«ЭТО УЖАСНАЯ МЫСЛЬ! СИГНАЛЫ НЕ ПРЕДНАЗНАЧЕНЫ ДЛЯ ЭТОГО! Просто скажите НЕТ».
Одним из главных механизмов межпроцессного взаимодействия (IPC) являются каналы, которые описаны в разделе 9.3 «Базовая межпроцессная коммуникация каналы и FIFO». Сигналы также можно использовать для очень простого IPC[111]. Это довольно грубо; получатель может лишь сказать, что поступил определенный сигнал. Хотя функция
sigaction()ЗАМЕЧАНИЕ. Как указывает цитата в начале, использование сигналов для IPC почти всегда является плохой мыслью. Мы рекомендуем по возможности избегать этого. Но нашей целью является научить вас, как использовать возможности Linux/Unix, включая их отрицательные моменты, оставляя за вами принятие информированного решения, что именно использовать.
Сигналы в качестве IPC для многих программ могут быть иногда единственным выбором. В частности, каналы не являются альтернативой, если две взаимодействующие программы не запущены общим родителем, а файлы FIFO могут не быть вариантом, если одна из взаимодействующих программ работает лишь со стандартными вводом и выводом. (Примером обычного использования сигналов являются определенные системные программы демонов, таких, как
xinetdТипичная высокоуровневая структура основанного на сигналах приложения выглядит таким образом:
for(;;){ /* Ожидание сигнала */ /* Обработка сигнала */}Оригинальным интерфейсом V7 для ожидания сигнала является
pause()#include /* POSIX */ int pause(void);pause()pause()Проблема в только что описанной высокоуровневой структуре приложения кроется в части «Обработка сигнала». Когда этот код запускается, вы не захотите обрабатывать другой сигнал; вы хотите завершить обработку текущего сигнала до перехода к следующему. Одним из возможных решений является структурирование обработчика сигнала таким образом, что он устанавливает флаг и проверяет его в главном цикле:
volatile sig_atomic_t signal_waiting = 0; /* true, если не обрабатываются сигналы */void handler(int sig) { signal_waiting = 1; /* Установка других данных, указывающих вид сигнала */В основном коде флаг проверяется:
for (;;) { if (!signal_waiting) { /* Если возник другой сигнал, */ pause(); /* этот код пропускается */ signal_waiting = 1; } /* Определение поступившего сигнала */ signal_waiting = 0; /* Обработка сигнала */}К сожалению, этот код изобилует условиями гонки:
for (;;) { if (!signal_waiting) { /* <--- Сигнал может появиться здесь, после проверки условия! */ pause(); /* pause() будет вызвана в любом случае */ signal_waiting = 1; } /* Определение поступившего сигнала <--- Сигнал может переписать здесь глобальные данные */ signal_waiting = 0; /* Обработка сигнала <--- То же и здесь, особенно для нескольких сигналов */}Решением является блокирование интересующего сигнала в любое время, кроме ожидания его появления. Например, предположим, что интересующим нас сигналом является
SIGINTvoid handler(int sig) { /* sig автоматически блокируется функцией sigaction() */ /* Установить глобальные данные, касающиеся этого сигнала */}int main(int argc, char **argv) { sigset_t set; struct sigaction act; /* ...обычная настройка, опции процесса и т.д. ... */ sigemptyset(&set); /* Создать пустой набор */ sigaddset(&set, SIGINT); /* Добавить в набор SIGINT */ sigprocmask(SIG_BLOCK, &set, NULL); /* Заблокировать его */ act.sa_mask = set; /* Настроить обработчик */ act.sa_handler = handler; act.sa_flags = 0; sigaction(sig, &act, NULL); /* Установить его */ ... /* Возможно, установить отдельные обработчики */ ... /* для других сигналов */ sigemptyset(&set); /* Восстановить пустой, допускает SIGINT */ for (;;) { sigsuspend(&set); /* Ждать появления SIGINT */ /* Обработка сигнала. SIGINT здесь снова блокируется */ } /* ...любой другой код... */ return 0;}Ключом к использованию этого является то, что
sigsuspend()SIGINTsigsuspend()sigsuspend()Вы легко можете расширить этот пример для нескольких сигналов, блокируя в
main()sigsuspended()При наличии всего этого не следует в новом коде использовать
pause()pause()sigpause()sigsuspend()sigaction()ЗАМЕЧАНИЕ. Приведенный выше код предполагает, что маска сигналов процесса начинается пустой. Код изделия должен вместо этого работать с любой маской сигналов, имеющейся на момент запуска программы.
10.8. Важные сигналы специального назначения
Некоторые сигналы имеют особое назначение. Здесь мы опишем наиболее важные.
10.8.1. Сигнальные часы: sleep()
, alarm()
и SIGALARM
Часто бывает необходимо написать программу в виде
while (/* некоторое неверное условие */) {
/* подождать некоторое время */
}
Часто такая потребность возникает в сценариях оболочки, например, в ожидании регистрации определенного пользователя:
until who | grep '^arnold' > /dev/null
do
sleep 10
done
Два механизма, один низкоуровневый, другой высокоуровневый, позволяют работающему процессу узнать, когда истекло заданное количество секунд.
10.8.1.1. Труднее, но с большим контролем: alarm()
и SIGALARM
Основным строительным блоком является системный вызов
alarm()
:
#include /* POSIX */
unsigned int alarm(unsigned int seconds);
После того, как
alarm()
возвратится, программа продолжает работать. Однако, когда истекают seconds
секунд, ядро посылает процессу SIGALARM
. Действием по умолчанию является завершение процесса, но вы скорее всего вместо этого установите обработчик сигнала для SIGALARM
.
Возвращаемое значение либо 0, либо, если был установлен предыдущий сигнальный интервал, число секунд, остающихся до его завершения. Однако, для процесса имеется лишь один такой сигнальный интервал; предыдущий отменяется, а новый помещается на его место.
Преимуществом здесь является то, что со своим установленным обработчиком вы можете делать при поступлении сигнала все, что хотите. Недостаток же в том, что приходится быть готовым к работе в нескольких контекстах: основном контексте и контексте обработчика сигнала.
10.8.1.2. Простой и легкий: sleep()
Более легкий способ ожидания истечения фиксированного промежутка времени заключается в использовании функции
sleep()
:
#include /* POSIX */
unsigned int sleep(unsigned int seconds);
Возвращаемое значение равно 0, если процесс проспал все отведенное время. В противном случае возвращается оставшееся для сна время. Это последнее значение может возникнуть в случае, если появился сигнал, пока процесс дремал.
ЗАМЕЧАНИЕ. Функция
sleep()
часто реализуется через сочетание signal()
, alarm()
и pause()
. Такой подход делает опасным смешивание sleep()
с вашим собственным вызовом alarm()
(или расширенной функцией setitimer()
, описанной в разделе 14.3.3 «Интервальные таймеры setitimer()
и getitimer()
») Чтобы теперь узнать о функции nanosleep()
, см. раздел 14.3.4 «Более точные паузы: nanosleep()
».
sleep()alarm()SIGALARMЧасто бывает необходимо написать программу в виде
while (/* некоторое неверное условие */) { /* подождать некоторое время */}Часто такая потребность возникает в сценариях оболочки, например, в ожидании регистрации определенного пользователя:
until who | grep '^arnold' > /dev/nulldo sleep 10doneДва механизма, один низкоуровневый, другой высокоуровневый, позволяют работающему процессу узнать, когда истекло заданное количество секунд.
10.8.1.1. Труднее, но с большим контролем: alarm()
и SIGALARM
alarm()SIGALARMОсновным строительным блоком является системный вызов
alarm()#include /* POSIX */ unsigned int alarm(unsigned int seconds);После того, как
alarm()secondsSIGALARMSIGALARMВозвращаемое значение либо 0, либо, если был установлен предыдущий сигнальный интервал, число секунд, остающихся до его завершения. Однако, для процесса имеется лишь один такой сигнальный интервал; предыдущий отменяется, а новый помещается на его место.
Преимуществом здесь является то, что со своим установленным обработчиком вы можете делать при поступлении сигнала все, что хотите. Недостаток же в том, что приходится быть готовым к работе в нескольких контекстах: основном контексте и контексте обработчика сигнала.
10.8.1.2. Простой и легкий: sleep()
sleep()Более легкий способ ожидания истечения фиксированного промежутка времени заключается в использовании функции
sleep()#include /* POSIX */ unsigned int sleep(unsigned int seconds);Возвращаемое значение равно 0, если процесс проспал все отведенное время. В противном случае возвращается оставшееся для сна время. Это последнее значение может возникнуть в случае, если появился сигнал, пока процесс дремал.
ЗАМЕЧАНИЕ. Функция
sleep()signal()alarm()pause()sleep()alarm()setitimer()setitimer()getitimer()nanosleep()nanosleep()10.8.2. Сигналы, управляющие заданиями
Несколько сигналов используются для реализации управления заданиями — возможностью начинать и останавливать задания и перемещать их из фонового режима на передний план и обратно. На уровне пользователя вы, несомненно, проделывали это: использовали CTRL-Z для остановки задания,
bgfgСекция 9.2.1 «Обзор управления заданиями» описывает в общем, как осуществляется управление заданиями. Данный раздел завершает обзор, описав сигналы управления заданиями. поскольку иногда может понадобиться перехватить их непосредственно:
SIGTSTPЭтот сигнал осуществляет «остановку терминала». Это сигнал, который ядро посылает процессу, когда пользователь за терминалом (или окном, эмулирующим терминал) набирает определенный ключ. Обычно это CTRL-Z, аналогично тому, как CTRL-C обычно посылает
SIGINTДействием по умолчанию для
SIGTSTPviSIGTSTPSIGSTOPЭтот сигнал также останавливает процесс, но он не может быть перехвачен, заблокирован или проигнорирован. Он может быть использован в качестве последнего средства вручную (посредством команды
killSIGTSTPraise (SIGSTOP)SIGTTINSIGTTOUРанее эти сигналы были определены как «фоновое чтение из tty» и «фоновая запись в tty». tty является устройством терминала. В системах управления заданиями процессы, работающие в фоновом режиме, заблокированы от попыток чтения с терминала или записи в него. Когда процесс пытается осуществить любую из этих операций, ядро посылает ему соответствующий сигнал. Для обоих действием по умолчанию является остановка процесса. При желании можно перехватить эти сигналы, но для этого редко бывает необходимость.
SIGCONTЭтот сигнал вновь запускает остановленный процесс. Если процесс не остановлен, он игнорируется. При желании его можно перехватить, но опять-таки для большинства программ мало причин для осуществления этого. Продолжая наш пример, обработчик
SIGCONTКогда процесс остановлен, любые другие посланные ему сигналы становятся ожидающими. Исключением является
SIGKILLSIGKILLSIGCONT
10.8.3. Родительский надзор: три различные стратегии
Как описано в разделе 9.1.1 «Создание процесса:
fork()
», одним побочным эффектом вызова fork()
является создание между процессами отношений родитель-потомок. Родительский процесс может ждать завершения одного или более из своих потомков и получить статус завершения порожденного процесса посредством одного из семейства системных вызовов wait()
.
Завершившиеся порожденные процессы, которых никто не ожидал, называются зомби (zombies). Обычно каждый раз при завершении порожденного процесса ядро посылает родительскому процессу сигнал
SIGCHLD
[112]. Действием по умолчанию является игнорирование этого сигнала. В этом случае процессы зомби накапливаются до тех пор, пока родитель не вызовет wait()
или не закончится сам. В последнем случае процессы зомби получают в качестве нового родителя системный процесс init
(PID 1), который получает от них результаты как часть своей обычной работы. Сходным образом, активные потомки также получают родителем init
, и их результаты будут собраны при их завершении.
SIGCHLD
используется для большего, чем уведомление о завершении потомка. Каждый раз при остановке потомка (посредством одного из обсужденных ранее сигналов управления заданиями) родителю также посылается SIGCHLD
. Стандарт POSIX указывает, что SIGCHLD
«может быть послан» также, когда помок вновь запускается; очевидно, среди оригинальных Unix-систем имеются различия.
Сочетание флагов для поля
sa_flags
в struct sigation
и использование SIG_IGN
в качестве действия для SIGCHLD
позволяет изменить способ обработки ядром остановок, возобновления или завершения потомков.
Как и с сигналами в общем, описанные здесь интерфейсы и механизмы сложны, поскольку они развивались с течением времени.
10.8.3.1. Плохие родители: полное игнорирование потомков
Простейшим действием, которое вы можете сделать, является изменение действия для
SIGCHLD
на SIG_IGN
. В этом случае завершившиеся потомки не становятся зомби. Вместо этого статус их завершения отбрасывается, и они полностью удаляются из системы.
Другой возможностью, дающей такой же результат, является использование флага
SA_NOCLDWAIТ
. В коде:
/* Старый стиль: */ /* Новый стиль: */
signal(SIGCHLD, SIG_IGN); struct sigaction sa;
sa.sa_handler = SIG_IGN;
sa.sa_flags = SA_NOCLDWAIT;
sigemptyset(&sa.sa_mask);
sigaction(SIGCHLD, &sa, NULL);
10.8.3.2. Снисходительные родители: минимальный надзор
В качестве альтернативы можно беспокоиться лишь о завершении потомка и не интересоваться простыми изменениями состояния (остановке и возобновлении). В этом случае используйте флаг
SA_NOCLDSTOP
и установите обработчик сигнала, вызывающий wait()
(или родственную ей функцию) для получения данных процесса.
В общем вы не можете ожидать получать по одному сигналу
SIGCHLD
на каждого завершающегося потомка. Следует считать, что SIGCHLD
означает «завершился по крайней мере один потомок» и быть готовым собрать при обработке SIGCHLD
сведения о как можно большем числе потомков.
Следующая программа,
ch10-reap1.с
, блокирует SIGCHLD
до тех пор, пока не будет готова восстановить потомков.
1 /* ch10-reap1.с --- демонстрирует управление SIGCHLD с использованием цикла */
2
3 #include
4 #include
5 #include
6 #include
7 #include
8 #include
9
10 #define MAX_KIDS 42
11 #define NOT_USED -1
12
13 pid_t kids[MAX_KIDS];
14 size_t nkids = 0;
Массив потомков отслеживает ID порожденных процессов. Если элемент содержит
NOT_USED
, он не представляет необработанного потомка. (Его инициализируют строки 89–90 внизу) nkids
указывает, сколько значений в kids
следует проверить.
16 /* format_num --- вспомогательная функция, поскольку нельзя использовать [sf]printf() */
17
18 const char *format_num(int num)
19 {
20 #define NUMSIZ 30
21 static char buf[NUMSIZ];
22 int i;
23
24 if (num <= 0) {
25 strcpy(buf, "0");
26 return buf;
27 }
28
29 i = NUMSIZ - 1;
30 buf[i--] = '\0';
31
32 /* Преобразует цифры обратно в строку. */
33 do {
34 buf[i--] = (num % 10) + '0';
35 num /= 10;
36 } while (num > 0);
37
38 return &buf[i+1];
39 }
Поскольку обработчики сигналов не должны вызывать функции семейства
printf()
, мы предусмотрели для преобразования десятичного сигнала или номера PID в строку простую «вспомогательную» функцию format_num()
. Это примитивно, но работает.
41 /* childhandler --- перехват SIGCHLD, сбор сведений со всех доступных потомков */
42
43 void childhandler(int sig)
44 {
45 int status, ret;
46 int i;
47 char buf[100];
48 static const char entered[] = "Entered childhandler\n" ;
49 static const char exited[] = "Exited childhandler\n";
50
51 writed, entered, strlen(entered));
52 for (i =0; i < nkids; i++) {
53 if (kids[i] == NOT_USED)
54 continue;
55
56 retry:
57 if ((ret = waitpid(kids[i], &status, WNOHANG)) == kids[i]) {
58 strcpy(buf, "\treaped process ");
59 strcat(buf, format_num(ret));
60 strcat(buf, "\n");
61 write(1, buf, strlen(buf));
62 kids[i] = NOT_USED;
63 } else if (ret == 0) {
64 strcpy(buf, "\tpid ");
65 strcat(buf, format_num(kids[i]));
66 strcat(buf, " not available yet\n");
67 write(1, buf, strlen(buf));
68 } else if (ret == -1 && errno == EINTR) {
69 write(1, "\tretrying\n", 10);
70 goto retry;
71 } else {
72 strcpy(buf, "\twaitpid() failed: ");
73 strcat(buf, strerror(errno));
74 strcat(buf, "\n");
75 write(1, buf, strlen(buf));
76 }
77 }
78 write(1, exited, strlen(exited));
79 }
Строки 51 и 58 выводят «входное» и «завершающее» сообщения, так что мы можем ясно видеть, когда вызывается обработчик сигнала. Другие сообщения начинаются с ведущего символа TAB.
Главной частью обработчика сигнала является большой цикл, строки 52–77. Строки 53–54 проверяют на
NOT_USED
и продолжают цикл, если текущий слот не используется.
Строка 57 вызывает
waitpid()
с PID текущего элемента kids
. Мы предусмотрели опцию WNOHANG
, которая заставляет waitpid()
возвращаться немедленно, если затребованный потомок недоступен. Этот вызов необходим, так как возможно, что не все потомки завершились.
Основываясь на возвращенном значении, код предпринимает соответствующее действие. Строки 57–62 обрабатывают случай обнаружения потомка, выводя сообщение и помещая в соответствующий слот в
kids
значение NOT_USED
.
Строки 63–67 обрабатывают случай, когда затребованный потомок недоступен. В этом случае возвращается значение 0, поэтому выводится сообщение, и выполнение продолжается.
Строки 68–70 обрабатывают случай, при котором был прерван системный вызов. В этом случае самым подходящим способом обработки является
goto
обратно на вызов waitpid()
. (Поскольку main()
блокирует все сигналы при вызове обработчика сигнала [строка 96], это прерывание не должно случиться. Но этот пример показывает, как обработать все случаи.)
Строки 71–76 обрабатывают любую другую ошибку, выводя соответствующее сообщение об ошибке.
81 /* main --- установка связанных с порожденными процессами сведений и сигналов, создание порожденных процессов */
82
83 int main(int argc, char **argv)
84 {
85 struct sigaction sa;
86 sigset_t childset, emptyset;
87 int i;
88
89 for (i = 0; i < nkids; i++)
90 kids[i] = NOT_USED;
91
92 sigemptyset(&emptyset);
93
94 sa.sa_flags =
SA_NOCLDSTOP;
95 sa.sa_handler = childhandler;
96 sigfillset(&sa.sa_mask); /* блокировать все при вызове обработчика */
97 sigaction(SIGCHLD, &sa, NULL);
98
99 sigemptyset(&childset);
100 sigaddset(&childset, SIGCHLD);
101
102 sigprocmask(SIG_SETMASK, &childset, NULL); /* блокировать его в коде main */
103
104 for (nkids = 0; nkids < 5; nkids++) {
105 if ((kids[nkids] = fdrk()) == 0) {
106 sleep(3);
107 _exit(0);
108 }
109 }
110
111 sleep(5); /* дать потомкам возможность завершения */
112
113 printf("waiting for signal\n");
114 sigsuspend(&emptyset);
115
116 return 0;
117 }
Строки 89–90 инициализируют
kids
. Строка 92 инициализирует emptyset
. Строки 94–97 настраивают и устанавливают обработчик сигнала для SIGCHLD
. Обратите внимание на использование в строке 94 SA_NOCLDSTOP
, тогда как строка 96 блокирует все сигналы при вызове обработчика.
Строки 99–100 создают набор сигналов, представляющих
SIGCHLD
, а строка 102 устанавливает их в качестве маски сигналов процесса для программы.
Строки 104–109 создают пять порожденных процессов, каждый из которых засыпает на три секунды. По ходу дела они обновляют массив
kids
и переменную nkids
.
Строка 111 дает затем потомкам шанс завершиться, заснув на еще больший промежуток времени. (Это не гарантирует, что порожденные процессы завершатся, но шансы довольно велики.)
Наконец, строки 113–114 выводят сообщение и приостанавливаются, заменив маску сигналов процесса, блокирующую
SIGCHLD
, пустой маской. Это дает возможность появиться сигналу SIGCHLD
, что в свою очередь вызывает запуск обработчика сигнала. Вот что происходит:
$ ch10-reap1 /* Запуск программы */
waiting for signal
Entered childhandler
reaped process 23937
reaped process 23938
reaped process 23939
reaped process 23940
reaped process 23941
Exited childhandler
Обработчик сигнала собирает сведения о потомках за один проход.
Следующая программа,
ch10-reap2.c
, сходна с ch10-reap1.c
. Разница в том, что она допускает появление сигнала SIGCHLD
в любое время. Такое поведение увеличивает шанс получения более одного SIGCHLD
, но не гарантирует это. В результате обработчик сигнала все равно должен быть готов обработать в цикле несколько потомков.
1 /* ch10-reap2.c — демонстрирует управление SIGCHLD, один сигнал на потомка */
2
/* ...не изменившийся код пропущен... */
12
13 pid_t kids[MAX_KIDS];
14 size_t nkids = 0;
15 size_t kidsleft = 0; /* <<< Добавлено */
16
/* ...не изменившийся код пропущен... */
41
42 /* childhandler --- перехват SIGCHLD, опрос всех доступных потомков */
43
44 void childhandler(int sig)
45 {
46 int status, ret;
47 int i;
48 char buf[100];
49 static const char entered[] = "Entered childhandler\n";
50 static const char exited[] = "Exited childhandler\n";
51
52 write(1, entered, strlen(entered));
53 for (i = 0; i < nkids; i++) {
54 if (kids[i] == NOT_USED)
55 continue;
56
57 retry:
58 if ((ret = waitpid(kids[i], &status, WNOHANG)) == kids[i]) {
59 strcpy(buf, "\treaped process ");
60 strcat(buf, format_num(ret));
61 strcat(buf, "\n");
62 write(1, buf, strlen(buf));
63 kids[i] = NOT_USED;
64 kidsleft--; /* <<< Добавлено */
65 } else if (ret == 0) {
/* ...не изменившийся код пропущен... */
80 write(1, exited, strlen(exited));
81 }
Это идентично предыдущей версии за тем исключением, что у нас есть новая переменная,
kidsleft
, указывающая, сколько имеется не опрошенных потомков. Строки 15 и 64 помечают новый код.
83 /* main --- установка относящейся к порожденным процессам сведений
и сигналов, создание порожденных процессов */
84
85 int main(int argc, char **argv)
86 {
/* ...не изменившийся код пропущен... */
100
101 sigemptyset(&childset);
102 sigaddset(&childset, SIGCHLD);
103
104 /* sigprocmask(SIG_SETMASK, &childset, NULL); /* блокирование в коде main */
105
106 for (nkids = 0; nkids < 5; nkids++) {
107 if ((kids[nkids] = fork()) == 0) {
108 sleep(3);
109 _exit(0);
110 }
111 kidsleft++; /* <<< Added */
112 }
113
114 /* sleep(5); /* дать потомкам шанс завершиться */
115
116 while (kidsleft > 0) { /* <<< Добавлено */
117 printf("waiting for signals\n");
118 sigsuspend(&emptyset);
119 } /* <<< Добавлено */
120
121 return 0;
122 }
Здесь код также почти идентичен. Строки 104 и 114 закомментированы из предыдущей версии, а строки 111, 116 и 119 добавлены. Удивительно, при запуске поведение меняется в зависимости от версии ядра!
$ uname -a /* Отобразить версию системы */
Linux example1 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 GNU/Linux
$ ch10-reap2 /* Запустить программу */
waiting for signals
Entered childhandler /* Опрос одного потомка */
reaped process 2702
pid 2703 not available yet
pid 2704 not available yet
pid 2705 not available yet
pid 27 06 not available yet
Exited childhandler
waiting for signals
Entered childhandler /* И следующего */
reaped process 2703
pid 2704 not available yet
pid 2705 not available yet
pid 2706 not available yet
Exited childhandler
waiting for signals
Entered childhandler /* И так далее */
reaped process 2704
pid 2705 not available yet
pid 2706 not available yet
Exited childhandler
waiting for signals
Entered childhandler
reaped process 2705
pid 2706 not available yet
Exited childhandler
waiting for signals
Entered childhandler
reaped process 2706
Exited childhandler
В данном примере на каждый процесс поступает ровно один
SIGCHLD
! Хотя это прекрасно и полностью воспроизводимо на этой системе, это также необычно. Как на более раннем, так и на более позднем ядре и на Solaris программа получает один сигнал для более чем одного потомка:
$ uname -a /* Отобразить версию системы */
Linux example2 2.4.22-1.2115.npt1 #1 Wed Oct 29 15:42:51 EST 2003 i686 i686 i386 GNU/Linux
$ ch10-reap2 /* Запуск программы */
waiting for signals
Entered childhandler /* Обработчик сигнала вызван лишь однажды */
reaped process 9564
reaped process 9565
reaped process 9566
reaped process 9567
reaped process 9568
Exited childhandler
ЗАМЕЧАНИЕ. В коде для
ch10-reap2.c
есть один важный дефект — состояние гонки. Взгляните еще раз на строки 106–112 в ch10-reap2.c
. Что случится, если SIGCHLD
появится при исполнении этого кода? Массив kids
и переменные nkids
и kidsleft
могут оказаться разрушенными: код в main
добавляет новый процесс, но обработчик сигнала вычитает один.
Этот пример кода является отличным примером критического раздела; он не должен прерываться при исполнении. Правильным способом работы с этим кодом является заключение его между вызовами, которые сначала блокируют, а затем разблокируют
SIGCHLD
.
10.8.3.3. Строгий родительский контроль
Структура
siginfo_t
и перехватчик сигнала с тремя аргументами дают возможность узнать, что случилось с потомком. Для SIGCHLD поле si_code
структуры siginfo_t
указывает причину посылки сигнала (остановка, возобновление, завершение порожденного процесса и т.д.). В табл. 10.5 представлен полный список значений. Все они определены в качестве расширения XSI стандарта POSIX.
Следующая программа,
ch10-status.c
, демонстрирует использование структуры siginfo_t
.
1 /* ch10-status.c --- демонстрирует управление SIGCHLD, используя обработчик с 3 аргументами */
2
3 #include
4 #include
5 #include
6 #include
7 #include
8 #include
9
10 void manage(siginfo_t *si);
11
/* ...не изменившийся для format_num() код опущен... */
Таблица 10.5. Значения
si_code
XSI для SIGCHLD
Значение
Смысл
CLD_CONTINUED
Остановленный потомок был возобновлен.
CLD_DUMPED
Потомок завершился с ошибкой, создан образ процесса
CLD_EXITED
Потомок завершился нормально.
CLD_KILLED
Потомок был завершен сигналом
CLD_STOPPED
Порожденный процесс был остановлен.
CLD_TRAPPED
Трассируемый потомок остановлен (Это условие возникает, когда программа трассируется — либо из отладчика, либо для мониторинга реального времени В любом случае, вы вряд ли увидите его в обычных ситуациях.)
Строки 3–8 включают стандартные заголовочные файлы, строка 10 объявляет
manage()
, которая имеет дело с изменениями состояния потомка, а функция format_num()
не изменилась по сравнению с предыдущим.
37 /* childhandler --- перехват SIGCHLD, сбор данных лишь об одном потомке */
38
39 void childhandler(int sig, siginfo_t *si, void *context)
40 {
41 int status, ret;
42 int i;
43 char buf[100];
44 static const char entered[] = "Entered childhandler\n";
45 static const char exited[] = "Exited childhandler\n";
46
47 write(1, entered, strlen(entered));
48 retry:
49 if ((ret = waitpid(si->si_pid, &status, WNOHANG)) == si->si_pid) {
50 strcpy(buf, "\treaped process ");
51 strcat(buf, format_num(si->si_pid));
52 strcat(buf, "\n");
53 write(1, buf, strlen(buf));
54 manage(si); /* обработать то, что произошло */
55 } else if (ret > 0) {
56 strcpy(buf, "\treaped unexpected pid ");
57 strcat(buf, format_num(ret));
58 strcat(buf, "\n");
59 write(1, buf, strlen(buf));
60 goto retry; /* почему бы нет? */
61 } else if (ret == 0) {
62 strcpy(buf, "\tpid ");
63 strcat(buf, format_num(si->si_pid));
64 strcat(buf, " changed status\n");
65 write(1, buf, strlen(buf));
66 manage(si); /* обработать то, что произошло */
67 } else if (ret == -1 && errno == EINTR) {
68 write(1, "\tretrying\n", 10);
69 goto retry;
70 } else {
71 strcpy(buf, "\twaitpid() failed: ");
72 strcat(buf, strerror(errno));
73 strcat(buf, "\n");
74 write(1, buf, strlen(buf));
75 }
76
77 write(1, exited, strlen(exited));
78 }
Обработчик сигнала похож на показанные ранее. Обратите внимание на список аргументов (строка 39) и на то, что нет цикла.
Строки 49–54 обрабатывают завершение процесса, включая вызов
manage()
для вывода состояния.
Строки 55–60 обрабатывают случай неожиданного завершения потомка. Этого не должно происходить, поскольку обработчику сигнала передается специфическая для определенного порожденного процесса информация.
Строки 61–66 представляют для нас интерес: возвращаемое значение для изменений состояния равно 0.
manage()
имеет дело с деталями (строка 66).
Строки 67–69 обрабатывают прерывания, а строки 70–75 распоряжаются ошибками
80 /* child --- что сделать в порожденном процессе */
81
82 void child(void)
83 {
84 raise(SIGCONT); /* должен быть проигнорирован */
85 raise(SIGSTOP); /* заснуть, родитель снова разбудит */
86 printf("\t---> child restarted <---\n");
87 exit(42); /* нормальное завершение, дать возможность родителю получить значение */
88 }
Функция
child()
обрабатывает поведение порожденного процесса, предпринимая действия для уведомления родителя[113]. Строка 84 посылает SIGCONT
, что может вызвать получение родителем события CLD_CONTINUED
. Строка 85 посылает SIGSTOP
, который останавливает процесс (сигнал не может быть перехвачен) и вызывает для родителя событие CLD_STOPPED
. Когда родитель возобновляет порожденный процесс, последний выводит сообщение, что он снова активен, а затем завершается с известным статусом завершения.
90 /* main --- установка относящихся к порожденному процессу сведений
и сигналов, создание порожденного процесса */
91
92 int main(int argc, char **argv)
93 {
94 pid_t kid;
95 struct sigaction sa;
96 sigset_t childset, emptyset;
97
98 sigemptyset(&emptyset);
99
100 sa.sa_flags = SA_SIGINFO;
101 sa.sa_sigaction = childhandler;
102 sigfillset(&sa.sa_mask); /* при вызове обработчика все заблокировать */
103 sigaction(SIGCHLD, &sa, NULL);
104
105 sigemptyset(&childset);
106 sigaddset(&childset, SIGCHLD);
107
108 sigprocmask(SIG_SETMASK, &childset, NULL); /* блокировать его в коде main */
109
110 if ((kid = fork()) == 0)
111 child();
112
113 /* здесь выполняется родитель */
114 for (;;) {
115 printf("waiting for signals\n");
116 sigsuspend(&emptyset);
117 }
118
119 return 0;
120 }
Программа
main()
все устанавливает. Строки 100–103 помещают на место обработчик. Строка 100 устанавливает флаг SA_SIGINFO
таким образом, что используется обработчик с тремя аргументами. Строки 105–108 блокируют SIGCHLD
.
Строка 110 создает порожденный процесс. Строки 113–117 продолжаются в родителе, используя для ожидания входящих сигналов
sigsuspend()
.
123 /* manage --- разрешение различных событий, которые могут случиться с потомком */
124
125 void manage(siginfo_t *si)
126 {
127 char buf[100];
128
129 switch (si->si_code) {
130 case CLD_STOPPED:
131 write(1, "\tchild stopped, restarting\n", 27);
132 kill(si->si_pid, SIGCONT);
133 break;
134
135 case CLD_CONTINUED: /* not sent on Linux */
136 write(1, "\tchild continued\n", 17);
137 break;
138
139 case CLD_EXITED:
140 strcpy(buf, "\tchild exited with status ");
141 strcat(buf, format_num(si->si_status));
142 strcat(buf, "\n");
143 write(1, buf, strlen(buf));
144 exit(0); /* we're done */
145 break;
146
147 case CLD_DUMPED:
148 write(1, "\tchild dumped\n", 14);
149 break;
150
151 case CLD_KILLED:
152 write(1, " \tchild killed\n", 14);
153 break;
154
155 case CLD_TRAPPED:
156 write(1, "\tchild trapped\n", 15);
157 break;
158 }
159 }
Посредством функции
manage()
родитель обрабатывает изменение состояния в порожденном процессе, manage()
вызывается, когда изменяется состояние и когда порожденный процесс завершился.
Строки 130–133 обрабатывают случай, когда потомок остановился; родитель возобновляет его, посылая
SIGCONT
.
Строки 135–137 выводят уведомление о возобновлении потомка. Это событие на системах GNU/Linux не происходит, и стандарт POSIX использует в этом случае невыразительный язык, просто говоря, что это событие может появиться, а не появится.
Строки 139–145 обрабатывают случай, когда порожденный процесс завершается, выводя статус завершения. Для этой программы родитель также все сделал, поэтому код завершается, хотя в более крупной программе это не то действие, которое должно быть сделано.
Другие случаи более специализированные. В случае события
CLD_KILLED
для получения дополнительных сведений было бы полезным значение status
, заполненной функцией waitpid()
.
Вот что происходит при запуске:
$ ch10-status /* Запуск программы */
waiting for signals
Entered childhandler /* Вход в обработчик сигнала */
pid 24279 changed status
child stopped, restarting /* Обработчик действует */
Exited childhandler
waiting for signals
---> child restarted <--- /* Из потомка */
Entered childhandler
reaped process 24279 /* Обработчик родителя опрашивает потомка */
child exited with status 42
К сожалению, поскольку нет способа гарантировать доставку по одному
SIGCHLD
на каждый процесс, ваша программа должна быть готова восстановить несколько потомков за один проход.
Как описано в разделе 9.1.1 «Создание процесса:
fork()fork()wait()Завершившиеся порожденные процессы, которых никто не ожидал, называются зомби (zombies). Обычно каждый раз при завершении порожденного процесса ядро посылает родительскому процессу сигнал
SIGCHLDwait()initinitSIGCHLDSIGCHLDSIGCHLDСочетание флагов для поля
sa_flagsstruct sigationSIG_IGNSIGCHLDКак и с сигналами в общем, описанные здесь интерфейсы и механизмы сложны, поскольку они развивались с течением времени.
10.8.3.1. Плохие родители: полное игнорирование потомков
Простейшим действием, которое вы можете сделать, является изменение действия для
SIGCHLDSIG_IGNДругой возможностью, дающей такой же результат, является использование флага
SA_NOCLDWAIТ/* Старый стиль: */ /* Новый стиль: */signal(SIGCHLD, SIG_IGN); struct sigaction sa; sa.sa_handler = SIG_IGN; sa.sa_flags = SA_NOCLDWAIT; sigemptyset(&sa.sa_mask); sigaction(SIGCHLD, &sa, NULL);10.8.3.2. Снисходительные родители: минимальный надзор
В качестве альтернативы можно беспокоиться лишь о завершении потомка и не интересоваться простыми изменениями состояния (остановке и возобновлении). В этом случае используйте флаг
SA_NOCLDSTOPwait()В общем вы не можете ожидать получать по одному сигналу
SIGCHLDSIGCHLDSIGCHLDСледующая программа,
ch10-reap1.сSIGCHLD1 /* ch10-reap1.с --- демонстрирует управление SIGCHLD с использованием цикла */23 #include 4 #include 5 #include 6 #include 7 #include 8 #include 910 #define MAX_KIDS 4211 #define NOT_USED -11213 pid_t kids[MAX_KIDS];14 size_t nkids = 0;Массив потомков отслеживает ID порожденных процессов. Если элемент содержит
NOT_USEDnkidskids16 /* format_num --- вспомогательная функция, поскольку нельзя использовать [sf]printf() */1718 const char *format_num(int num)19 {20 #define NUMSIZ 3021 static char buf[NUMSIZ];22 int i;2324 if (num <= 0) {25 strcpy(buf, "0");26 return buf;27 }2829 i = NUMSIZ - 1;30 buf[i--] = '\0';3132 /* Преобразует цифры обратно в строку. */33 do {34 buf[i--] = (num % 10) + '0';35 num /= 10;36 } while (num > 0);3738 return &buf[i+1];39 }Поскольку обработчики сигналов не должны вызывать функции семейства
printf()format_num()41 /* childhandler --- перехват SIGCHLD, сбор сведений со всех доступных потомков */4243 void childhandler(int sig)44 {45 int status, ret;46 int i;47 char buf[100];48 static const char entered[] = "Entered childhandler\n" ;49 static const char exited[] = "Exited childhandler\n";5051 writed, entered, strlen(entered));52 for (i =0; i < nkids; i++) {53 if (kids[i] == NOT_USED)54 continue;5556 retry:57 if ((ret = waitpid(kids[i], &status, WNOHANG)) == kids[i]) {58 strcpy(buf, "\treaped process ");59 strcat(buf, format_num(ret));60 strcat(buf, "\n");61 write(1, buf, strlen(buf));62 kids[i] = NOT_USED;63 } else if (ret == 0) {64 strcpy(buf, "\tpid ");65 strcat(buf, format_num(kids[i]));66 strcat(buf, " not available yet\n");67 write(1, buf, strlen(buf));68 } else if (ret == -1 && errno == EINTR) {69 write(1, "\tretrying\n", 10);70 goto retry;71 } else {72 strcpy(buf, "\twaitpid() failed: ");73 strcat(buf, strerror(errno));74 strcat(buf, "\n");75 write(1, buf, strlen(buf));76 }77 }78 write(1, exited, strlen(exited));79 }Строки 51 и 58 выводят «входное» и «завершающее» сообщения, так что мы можем ясно видеть, когда вызывается обработчик сигнала. Другие сообщения начинаются с ведущего символа TAB.
Главной частью обработчика сигнала является большой цикл, строки 52–77. Строки 53–54 проверяют на
NOT_USEDСтрока 57 вызывает
waitpid()kidsWNOHANGwaitpid()Основываясь на возвращенном значении, код предпринимает соответствующее действие. Строки 57–62 обрабатывают случай обнаружения потомка, выводя сообщение и помещая в соответствующий слот в
kidsNOT_USEDСтроки 63–67 обрабатывают случай, когда затребованный потомок недоступен. В этом случае возвращается значение 0, поэтому выводится сообщение, и выполнение продолжается.
Строки 68–70 обрабатывают случай, при котором был прерван системный вызов. В этом случае самым подходящим способом обработки является
gotowaitpid()main()Строки 71–76 обрабатывают любую другую ошибку, выводя соответствующее сообщение об ошибке.
81 /* main --- установка связанных с порожденными процессами сведений и сигналов, создание порожденных процессов */8283 int main(int argc, char **argv)84 {85 struct sigaction sa;86 sigset_t childset, emptyset;87 int i;8889 for (i = 0; i < nkids; i++)90 kids[i] = NOT_USED;9192 sigemptyset(&emptyset);9394 sa.sa_flags =SA_NOCLDSTOP;95 sa.sa_handler = childhandler;96 sigfillset(&sa.sa_mask); /* блокировать все при вызове обработчика */97 sigaction(SIGCHLD, &sa, NULL);9899 sigemptyset(&childset);100 sigaddset(&childset, SIGCHLD);101102 sigprocmask(SIG_SETMASK, &childset, NULL); /* блокировать его в коде main */103104 for (nkids = 0; nkids < 5; nkids++) {105 if ((kids[nkids] = fdrk()) == 0) {106 sleep(3);107 _exit(0);108 }109 }110111 sleep(5); /* дать потомкам возможность завершения */112113 printf("waiting for signal\n");114 sigsuspend(&emptyset);115 116 return 0;117 }Строки 89–90 инициализируют
kidsemptysetSIGCHLDSA_NOCLDSTOPСтроки 99–100 создают набор сигналов, представляющих
SIGCHLDСтроки 104–109 создают пять порожденных процессов, каждый из которых засыпает на три секунды. По ходу дела они обновляют массив
kidsnkidsСтрока 111 дает затем потомкам шанс завершиться, заснув на еще больший промежуток времени. (Это не гарантирует, что порожденные процессы завершатся, но шансы довольно велики.)
Наконец, строки 113–114 выводят сообщение и приостанавливаются, заменив маску сигналов процесса, блокирующую
SIGCHLDSIGCHLD$ ch10-reap1 /* Запуск программы */waiting for signalEntered childhandler reaped process 23937 reaped process 23938 reaped process 23939 reaped process 23940 reaped process 23941Exited childhandlerОбработчик сигнала собирает сведения о потомках за один проход.
Следующая программа,
ch10-reap2.cch10-reap1.cSIGCHLDSIGCHLD1 /* ch10-reap2.c — демонстрирует управление SIGCHLD, один сигнал на потомка */2 /* ...не изменившийся код пропущен... */1213 pid_t kids[MAX_KIDS];14 size_t nkids = 0;15 size_t kidsleft = 0; /* <<< Добавлено */16 /* ...не изменившийся код пропущен... */4142 /* childhandler --- перехват SIGCHLD, опрос всех доступных потомков */4344 void childhandler(int sig)45 {46 int status, ret;47 int i;48 char buf[100];49 static const char entered[] = "Entered childhandler\n";50 static const char exited[] = "Exited childhandler\n";5152 write(1, entered, strlen(entered));53 for (i = 0; i < nkids; i++) {54 if (kids[i] == NOT_USED)55 continue;5657 retry:58 if ((ret = waitpid(kids[i], &status, WNOHANG)) == kids[i]) {59 strcpy(buf, "\treaped process ");60 strcat(buf, format_num(ret));61 strcat(buf, "\n");62 write(1, buf, strlen(buf));63 kids[i] = NOT_USED;64 kidsleft--; /* <<< Добавлено */65 } else if (ret == 0) { /* ...не изменившийся код пропущен... */80 write(1, exited, strlen(exited));81 }Это идентично предыдущей версии за тем исключением, что у нас есть новая переменная,
kidsleft83 /* main --- установка относящейся к порожденным процессам сведений и сигналов, создание порожденных процессов */8485 int main(int argc, char **argv)86 { /* ...не изменившийся код пропущен... */100101 sigemptyset(&childset);102 sigaddset(&childset, SIGCHLD);103104 /* sigprocmask(SIG_SETMASK, &childset, NULL); /* блокирование в коде main */105106 for (nkids = 0; nkids < 5; nkids++) {107 if ((kids[nkids] = fork()) == 0) {108 sleep(3);109 _exit(0);110 }111 kidsleft++; /* <<< Added */112 }113114 /* sleep(5); /* дать потомкам шанс завершиться */115116 while (kidsleft > 0) { /* <<< Добавлено */117 printf("waiting for signals\n");118 sigsuspend(&emptyset);119 } /* <<< Добавлено */120121 return 0;122 }Здесь код также почти идентичен. Строки 104 и 114 закомментированы из предыдущей версии, а строки 111, 116 и 119 добавлены. Удивительно, при запуске поведение меняется в зависимости от версии ядра!
$ uname -a /* Отобразить версию системы */Linux example1 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 GNU/Linux$ ch10-reap2 /* Запустить программу */waiting for signalsEntered childhandler /* Опрос одного потомка */ reaped process 2702 pid 2703 not available yet pid 2704 not available yet pid 2705 not available yet pid 27 06 not available yetExited childhandlerwaiting for signalsEntered childhandler /* И следующего */ reaped process 2703 pid 2704 not available yet pid 2705 not available yet pid 2706 not available yetExited childhandlerwaiting for signalsEntered childhandler /* И так далее */ reaped process 2704 pid 2705 not available yet pid 2706 not available yetExited childhandlerwaiting for signalsEntered childhandler reaped process 2705 pid 2706 not available yetExited childhandlerwaiting for signalsEntered childhandler reaped process 2706Exited childhandlerВ данном примере на каждый процесс поступает ровно один
SIGCHLD$ uname -a /* Отобразить версию системы */Linux example2 2.4.22-1.2115.npt1 #1 Wed Oct 29 15:42:51 EST 2003 i686 i686 i386 GNU/Linux$ ch10-reap2 /* Запуск программы */waiting for signalsEntered childhandler /* Обработчик сигнала вызван лишь однажды */ reaped process 9564 reaped process 9565 reaped process 9566 reaped process 9567 reaped process 9568Exited childhandlerЗАМЕЧАНИЕ. В коде для
ch10-reap2.cch10-reap2.cSIGCHLDkidsnkidskidsleftmainЭтот пример кода является отличным примером критического раздела; он не должен прерываться при исполнении. Правильным способом работы с этим кодом является заключение его между вызовами, которые сначала блокируют, а затем разблокируют
SIGCHLD10.8.3.3. Строгий родительский контроль
Структура
siginfo_tsi_codesiginfo_tСледующая программа,
ch10-status.csiginfo_t1 /* ch10-status.c --- демонстрирует управление SIGCHLD, используя обработчик с 3 аргументами */23 #include 4 #include 5 #include 6 #include 7 #include 8 #include 910 void manage(siginfo_t *si);11/* ...не изменившийся для format_num() код опущен... */Таблица 10.5. Значения
si_codeSIGCHLD| Значение | Смысл |
|---|---|
|
Остановленный потомок был возобновлен. |
|
Потомок завершился с ошибкой, создан образ процесса |
|
Потомок завершился нормально. |
|
Потомок был завершен сигналом |
|
Порожденный процесс был остановлен. |
|
Трассируемый потомок остановлен (Это условие возникает, когда программа трассируется — либо из отладчика, либо для мониторинга реального времени В любом случае, вы вряд ли увидите его в обычных ситуациях.) |
Строки 3–8 включают стандартные заголовочные файлы, строка 10 объявляет
manage()format_num()37 /* childhandler --- перехват SIGCHLD, сбор данных лишь об одном потомке */3839 void childhandler(int sig, siginfo_t *si, void *context)40 {41 int status, ret;42 int i;43 char buf[100];44 static const char entered[] = "Entered childhandler\n";45 static const char exited[] = "Exited childhandler\n";4647 write(1, entered, strlen(entered));48 retry:49 if ((ret = waitpid(si->si_pid, &status, WNOHANG)) == si->si_pid) {50 strcpy(buf, "\treaped process ");51 strcat(buf, format_num(si->si_pid));52 strcat(buf, "\n");53 write(1, buf, strlen(buf));54 manage(si); /* обработать то, что произошло */55 } else if (ret > 0) {56 strcpy(buf, "\treaped unexpected pid ");57 strcat(buf, format_num(ret));58 strcat(buf, "\n");59 write(1, buf, strlen(buf));60 goto retry; /* почему бы нет? */61 } else if (ret == 0) {62 strcpy(buf, "\tpid ");63 strcat(buf, format_num(si->si_pid));64 strcat(buf, " changed status\n");65 write(1, buf, strlen(buf));66 manage(si); /* обработать то, что произошло */67 } else if (ret == -1 && errno == EINTR) {68 write(1, "\tretrying\n", 10);69 goto retry;70 } else {71 strcpy(buf, "\twaitpid() failed: ");72 strcat(buf, strerror(errno));73 strcat(buf, "\n");74 write(1, buf, strlen(buf));75 }7677 write(1, exited, strlen(exited));78 }Обработчик сигнала похож на показанные ранее. Обратите внимание на список аргументов (строка 39) и на то, что нет цикла.
Строки 49–54 обрабатывают завершение процесса, включая вызов
manage()Строки 55–60 обрабатывают случай неожиданного завершения потомка. Этого не должно происходить, поскольку обработчику сигнала передается специфическая для определенного порожденного процесса информация.
Строки 61–66 представляют для нас интерес: возвращаемое значение для изменений состояния равно 0.
manage()Строки 67–69 обрабатывают прерывания, а строки 70–75 распоряжаются ошибками
80 /* child --- что сделать в порожденном процессе */8182 void child(void)83 {84 raise(SIGCONT); /* должен быть проигнорирован */85 raise(SIGSTOP); /* заснуть, родитель снова разбудит */86 printf("\t---> child restarted <---\n");87 exit(42); /* нормальное завершение, дать возможность родителю получить значение */88 }Функция
child()SIGCONTCLD_CONTINUEDSIGSTOPCLD_STOPPED90 /* main --- установка относящихся к порожденному процессу сведений и сигналов, создание порожденного процесса */9192 int main(int argc, char **argv)93 {94 pid_t kid;95 struct sigaction sa;96 sigset_t childset, emptyset;9798 sigemptyset(&emptyset);99100 sa.sa_flags = SA_SIGINFO;101 sa.sa_sigaction = childhandler;102 sigfillset(&sa.sa_mask); /* при вызове обработчика все заблокировать */103 sigaction(SIGCHLD, &sa, NULL);104105 sigemptyset(&childset);106 sigaddset(&childset, SIGCHLD);107108 sigprocmask(SIG_SETMASK, &childset, NULL); /* блокировать его в коде main */109110 if ((kid = fork()) == 0)111 child();112113 /* здесь выполняется родитель */114 for (;;) {115 printf("waiting for signals\n");116 sigsuspend(&emptyset);117 }118119 return 0;120 }Программа
main()SA_SIGINFOSIGCHLDСтрока 110 создает порожденный процесс. Строки 113–117 продолжаются в родителе, используя для ожидания входящих сигналов
sigsuspend()123 /* manage --- разрешение различных событий, которые могут случиться с потомком */124125 void manage(siginfo_t *si)126 {127 char buf[100];128129 switch (si->si_code) {130 case CLD_STOPPED:131 write(1, "\tchild stopped, restarting\n", 27);132 kill(si->si_pid, SIGCONT);133 break;134135 case CLD_CONTINUED: /* not sent on Linux */136 write(1, "\tchild continued\n", 17);137 break;138139 case CLD_EXITED:140 strcpy(buf, "\tchild exited with status ");141 strcat(buf, format_num(si->si_status));142 strcat(buf, "\n");143 write(1, buf, strlen(buf));144 exit(0); /* we're done */145 break;146147 case CLD_DUMPED:148 write(1, "\tchild dumped\n", 14);149 break;150151 case CLD_KILLED:152 write(1, " \tchild killed\n", 14);153 break;154155 case CLD_TRAPPED:156 write(1, "\tchild trapped\n", 15);157 break;158 }159 }Посредством функции
manage()manage()Строки 130–133 обрабатывают случай, когда потомок остановился; родитель возобновляет его, посылая
SIGCONTСтроки 135–137 выводят уведомление о возобновлении потомка. Это событие на системах GNU/Linux не происходит, и стандарт POSIX использует в этом случае невыразительный язык, просто говоря, что это событие может появиться, а не появится.
Строки 139–145 обрабатывают случай, когда порожденный процесс завершается, выводя статус завершения. Для этой программы родитель также все сделал, поэтому код завершается, хотя в более крупной программе это не то действие, которое должно быть сделано.
Другие случаи более специализированные. В случае события
CLD_KILLEDstatuswaitpid()Вот что происходит при запуске:
$ ch10-status /* Запуск программы */waiting for signalsEntered childhandler /* Вход в обработчик сигнала */ pid 24279 changed status child stopped, restarting /* Обработчик действует */Exited childhandlerwaiting for signals ---> child restarted <--- /* Из потомка */Entered childhandler reaped process 24279 /* Обработчик родителя опрашивает потомка */ child exited with status 42К сожалению, поскольку нет способа гарантировать доставку по одному
SIGCHLD
10.9. Сигналы, передающиеся через fork()
и exec()
fork()exec()Когда программа вызывает
fork()alarm()Когда процесс вызывает одну из функций
exec()• Сигналы с установленным действием по умолчанию остаются с этим действием по умолчанию.
• Все перехваченные сигналы сбрасываются в состояние с действием по умолчанию.
• Сигналы, которые игнорируются, продолжают игнорироваться. Особым случаем является
SIGCHLDSIGCHLDexec()SIGCHLD• Сигналы, заблокированные до вызова
exec()• Любые ожидающие сигналы (те, которые появились, но были заблокированы) сбрасываются. Новая программа не может их получить.
• Временной интервал, остающийся для
alarm()alarmexec()SIGALARMfork()alarmexec()ЗАМЕЧАНИЕ. Многие, если не все. программы предполагают, что сигналы инициализированы действиями по умолчанию и что заблокированных сигналов нет. Таким образом, особенно если не вы писали программу, запускаемую с помощью
exec()exec()10.10. Резюме
«Наша история до настоящего времени, эпизод III»
• Интерфейсы обработки сигналов развились от простых, но подверженных состояниям гонок, до сложных, но надежных. К сожалению, множественность интерфейсов затрудняет их изучение по сравнению с другими API Linux/Unix.
• У каждого сигнала есть связанное с ним действие. Действие может быть одним из следующих: игнорирование сигнала; выполнение действия системы по умолчанию или вызов предоставленного пользователем обработчика. Действие системы по умолчанию, в свою очередь, является одним из следующих: игнорирование сигнала, завершение процесса; завершение процесса с созданием его образа; остановка процесса или возобновление процесса, если он остановлен.
•
signal()raise()signal()raise()signal()raise()• POSIX определяет функцию
bsd_signal()signal()• Действия, происходящие после возвращения из обработчика, варьируют в зависимости от системы. Традиционные системы (V7, Solaris, возможно, и другие) восстанавливают действие сигнала по умолчанию. На этих системах прерванный системный вызов возвращает -1, устанавливая в
errnoEINTRerrnoEINTR• GNU/Linux придерживается POSIX, который похож, но не идентичен с BSD. Если не было перемещения данных, системный вызов возвращает -1/
EINTRsigaction()• Обработчики сигналов, используемые с
signal()volatile sig_atomic_t• Первоначальной попыткой создания надежных сигналов был API сигналов System V Release 3 (скопированный из BSD 4.0). Не используйте его в новом коде.
• POSIX API содержит множество компонентов:
• маску сигналов процесса, перечисляющую текущие заблокированные сигналы;
• тип
sigset_tsigfillset()sigemptyset()sigaddset()sigdelset()sigismember()• функцию
sigprocmask()• функцию
sigpending()• API
sigaction()struct sigactionВсе эти возможности вместе используют блокирование сигналов и маску сигналов процесса для предоставления надежных сигналов. Более того, через различные флаги можно получить повторно запускаемые системные вызовы и более подходящие обработчики сигналов, которые получают большую информацию о причине, вызвавшей определенный сигнал (структура
siginfo_t• Механизмами POSIX для посылки сигналов являются
kill()killpg()raise()• Сигналы могут использоваться в качестве механизма IPC, хотя такой способ является плохим способом структурирования приложения, подверженным состояниям гонок. Если кто-то держит приставленным к вашей голове ружье, чтобы заставить вас работать таким способом, для правильной работы используйте тщательное блокирование сигналов и интерфейс
sigaction()•
SIGALARMalarm()pause()sleep()sleep()alarm()pause()sigsuspend()• Сигналы управления заданиями реализуют управление заданиями для оболочки. Большую часть времени следует оставлять их с установленными действиями по умолчанию, но полезно понимать, что иногда имеет смысл их перехватывать.
• Перехват
SIGCHLDsignal(SIGCHLD, SIG_IGN)sigaction()SA_NOCLDWAITsigaction()SA_NOCLDSTOPSIGCHLDSIGCHLDsigaction()SA_NOCLDSTOP• После
fork()exec()Упражнения
1. Реализуйте
bsd_signal()sigaction()2. Если у вас не установлен GNU/Linux, запустите на своей системе
ch10-catchint3. Реализуйте функции System V Release 3
sighold()sigrelse()sigignore()sigpause()sigset()sigaction()4. Потренируйте свои навыки в жонглировании битами. В предположении, что сигнал 0 отсутствует и что имеется не более 31 сигналов, предусмотрите
typedefsigset_tsigemptyset()sigfillset()sigaddset()sigdelset()sigismember()5. Еще немного потренируйте свои навыки жонглирования битами. Повторите предыдущее упражнение, на этот раз предположив, что наибольшим сигналом является 42.
6. Теперь, когда вы сделали предыдущие два упражнения, найдите
sigemptyset()#include7. В разделе 10.7 «Сигналы для межпроцессного взаимодействия» мы упомянули, что код изделия должен работать с начальной маской сигналов процесса, добавляя и удаляя блокируемые сигналы в вызове
sigsuspend()8. Напишите свою собственную версию команды
killkill [-s имя-сигнала] pid ...Если сигнал не указан, программа должна посылать
SIGTERM9. Как вы думаете, почему в современных оболочках, таких, как Bash и ksh93,
kill10. (Трудное) Реализуйте
sleep()alarm()signal()pause()SIGALRM11. Поэкспериментируйте с
ch10-reap.csigsuspend()12. Попробуйте заставить
ch10-reap2.ckidsnkidskidsleft
Глава 11
Права доступа и ID пользователей и групп
Linux, вслед за Unix, является многопользовательской системой. В отличие от большинства операционных систем для персональных компьютеров,[114] в которых имеется лишь один пользователь и в которых, кто бы ни находился перед компьютером, он имеет полный контроль, Linux и Unix различают файлы и процессы по владельцам и группам, которым они принадлежат. В данной главе мы исследуем проверку прав доступа и рассмотрим API для получения и установки идентификаторов владельцев и групп.
11.1. Проверка прав доступа
Как мы видели в разделе 5.4.2 «Получение информации о файлах», файловая система хранит идентификаторы владельца и группы файла в виде числовых значений; это типы
uid_t
и gid_t
соответственно. Для краткости мы используем для «идентификатора владельца (пользователя)» и «идентификатора группы» сокращения UID и GID соответственно.
У каждого процесса есть несколько связанных с ним идентификаторов пользователя и группы. Для проверки прав доступа в качестве упрощения используется один определенный UID и GID; когда UID процесса совпадает с UID файла, биты прав доступа пользователя файла диктуют, что может сделать процесс с файлом. Если они не совпадают, система проверяет GID процесса с GID файла; при совпадении используются права доступа группы; в противном случае, используются права доступа для «остальных».
Помимо файлов, UID определяет, как один процесс может повлиять на другой путем посылки сигналов. Сигналы описаны в главе 10 «Сигналы».
Наконец, особым случаем является суперпользователь,
root
. root
идентифицируется по UID, равным 0. Когда у процесса UID равен 0, ядро позволяет ему делать все, что он захочет: читать, записывать или удалять файлы, посылать сигналы произвольным процессам и т.д. (POSIX в этом отношении более непонятный, ссылаясь на процессы с «соответствующими привилегиями». Этот язык, в свою очередь, просочился в справочные страницы GNU/Linux и справочное руководство GLIBC online Info manual. Некоторые операционные системы действительно разделяют привилегии пользователей, и Linux также движется в этом направлении. Тем не менее, в настоящее время «соответствующие привилегии» означает просто процессы с UID, равным 0.)
11.1.1. Действительные и эффективные ID
Номера UID и GID подобны персональным удостоверениям личности. Иногда вам может понадобиться более одного удостоверяющего документа. Например, у вас могут быть водительские права или правительственное удостоверение личности[115]. Вдобавок, ваш университет или компания могли выдать вам свои удостоверения личности. То же самое относится и к процессам; они имеют при себе множество следующих номеров UID и GID:
Действительный ID пользователя
UID пользователя, породившего процесс.
Эффективный ID пользователя
UID, использующийся при большинстве проверок прав доступа. В большинстве случаев эффективный и действительный UID являются одним и тем же. Эффективный UID может отличаться от действительного при запуске, если установлен бит setuid файла исполняемой программы и файл не принадлежит пользователю, запускающему программу. (Вскоре будут дополнительные сведения.)
Сохраненный set-user ID
Первоначальный эффективный UID при запуске программы (после выполнения exec.) Имеет значение при проверке прав доступа, когда процессу нужно менять действительный и эффективный UID в ходе работы. Эта концепция пришла из System V.
Действительный ID группы
GID пользователя, создавшего процесс, аналогично действительному UID.
Эффективный ID группы
GID, использующийся для проверки прав доступа, аналогично эффективному GID.
Сохраненный set-group ID
Первоначальный эффективный GID при запуске программы, аналогично сохраненному set-user ID.
Набор дополнительных групп
4.2 BSD ввело понятие набора групп. Помимо действительного и эффективного GID. у каждого процесса есть некоторый набор дополнительных групп, которым он принадлежит в одно и то же время. Таким образом, когда проверка прав доступа осуществляется для группы файла, ядро проверяет не только эффективный GID, но также и все GID в наборе групп.
Каждый процесс может получить все из этих значений. Обычный (не принадлежащий суперпользователю) процесс может переключать свои действительные и эффективные ID пользователя и группы. Процесс
root
(с эффективным UID, равным 0) может также устанавливать значения таким образом, как ему нужно (хотя это может оказаться односторонней операцией)
11.1.2. Биты Setuid и Setgid
Биты setuid и setgid[116] в правах доступа к файлу заставляют процесс принять эффективный UID или GID, который отличается от действительного. Эти биты накладываются на файл вручную с помощью команды
chmod
:
$ chmod u+s myprogram /* Добавить бит setuid */
$ chmod g+s myprogram /* Добавить бит setgid */
$ ls -l myprogram
-rwsr-sr-x 1 arnold devel 4573 Oct 9 18:17 myprogram
Наличие символа s в месте, где обычно находится символ x, указывает на присутствие битов setuid/setgid.
Как упоминалось в разделе 8.2.1 «Использование опций монтирования», опция
nosuid
команды mount для файловой системы предотвращает обращение ядра к битам setuid и setgid. Это мера безопасности; например, пользователь с домашней системой GNU/Linux мог бы вручную изготовить гибкий диск с копией исполняемого файла оболочки с setuid, устанавливающей в root
. Но если система GNU/Linux в офисе или лаборатории монтирует файловые системы с гибкими дисками с опцией nosuid
, запуск этой оболочки не предоставит доступа с правами root
[117].
Каноническим (и возможно, злоупотребляемым) примером программы с setuid является игровая программа. Представьте, что вы написали по-настоящему крутую игру и хотите позволить пользователям системы играть в нее. Игра содержит файл счета, в котором перечислены высшие достижения.
Если вы не являетесь системным администратором, вы не можете создать отдельную группу только для тех пользователей, которым разрешено играть в игру и тем самым записывать в файл счета. Но если вы сделаете файл доступным для записи любому, чтобы каждый смог поиграть в игру, тогда каждый сможет также сжульничать и поместить наверх любое имя.
Однако, заставив программу устанавливать setuid на вас, пользователи, запускающие игру, получат ваш UID в качестве своего эффективного UID. Игровая программа сможет при этом открывать и обновлять файл счета по мере необходимости, но произвольные пользователи не смогут прийти и отредактировать его. (Вы подвергаете себя также большинству опасностей при программировании setuid; например, если в игровой программе есть дыра, которую можно использовать для запуска оболочки, действующей от вашего имени, все ваши файлы оказываются доступными для удаления или изменения. Это действительно устрашающая мысль.)
Та же логика применяется к программам setgid, хотя на практике программы с setgid используются гораздо реже, чем с setuid (Это также плохо; многие вещи, которые делаются программами с setuid
root
, легко могут быть сделаны программами с setgid или программами, которые вместо этого устанавливают setuid на обычного пользователя[118]).
11.2. Получение ID пользователя и группы
Получение от системы сведений о UID и GID просто. Функции следующие:
#include /* POSIX */
uid_t getuid(void); /* Действительный и эффективный UID */
uid_t geteuid(void);
gid_t getgid(void); /* Действительный и эффективный GID */
gid_t getegid(void);
int getgroups(int size, gid_t list[]); /* Список дополнительных групп*/
Функции:
uid_t getuid(void)
Возвращает действительный UID.
uid_t geteuid(void)
Возвращает эффективный UID.
gid_t getgid(void)
Возвращает действительный GID.
gid_t getegid(void)
Возвращает эффективный GID.
int getgroups(int size, gid_t list[])
Заполняет до
size
элементов массива list
из набора дополнительных групп процесса. Возвращаемое значение является числом заполненных элементов или -1 при ошибке. Включается ли в набор также эффективный GID, зависит от реализации. На системах, совместимых с POSIX, можно передать в size нулевое значение; в этом случае getgroups()
возвращает число групп в наборе групп процесса. Затем можно использовать это значение для динамического выделения массива достаточного размера. На не-POSIX системах константа NGROUPS_MAX
определяет максимально допустимый размер для массива list
. Эту константу можно найти в современных системах в
, а в старых системах в
. Вскоре мы представим пример.
Возможно, вы заметили, что для получения сохраненных значений set-user ID или set-group ID нет вызовов. Это просто первоначальные значения эффективных UID и GID. Таким образом, для получения шести значений в начале программы вы можете использовать код наподобие этого:
uid_t ruid, euid, saved_uid;
gid_t rgid, egid, saved_gid;
int main(int argc, char **argv) {
ruid = getuid();
euid = saved_uid = geteuid();
rgid = getgid();
egid = saved_gid = getegid();
/* ...оставшаяся программа... */
}
Вот пример получения набора групп. В качестве расширения
gawk
предоставляет доступ на уровне awk
к значениям действительных и эффективных UID и GID и дополнительному набору групп. Для этого он должен получить набор групп. Следующая функция из main.c
в дистрибутиве gawk
3.1.3:
1080 /* init_groupset --- инициализация набора групп */
1081
1082 static void
1083 init_groupset()
1084 {
1085 #if defined(HAVE_GETGROUPS) && defined(NGROUPS_MAX) && NGROUPS_MAX > 0
1086 #ifdef GETGROUPS_NOT_STANDARD
1087 /* Для систем, которые не отвечают стандарту, используйте старый способ */
1088 ngroups = NGROUPS_MAX;
1089 #else
1090 /*
1091 * Если оба аргумента при вызове равны 0, возвращаемое
1092 * значение является общим числом групп.
1093 */
1094 ngroups = getgroups(0, NULL);
1095 #endif
1096 if (ngroups == -1)
1097 fatal(_("could not find groups: %s"), strerror(errno));
1098 else if (ngroups == 0)
1099 return;
1100
1101 /* заполнить группы */
1102 emalloc(groupset, GETGROUPS_T*, ngroups * sizeof(GETGROUPS_T), "init_groupset");
1103
1104 ngroups = getgroups(ngroups, groupset);
1105 if (ngroups == -1)
1106 fatal(_("could not find groups: %s"), strerror(errno));
1107 #endif
1108 }
Переменные
ngroups
и groupset
глобальные; их объявления не показаны. Макрос GETGROUPS_T
(строка 1102) является типом для использования со вторым аргументом: на системе POSIX это gid_t
, в противном случае int
.
Строки 1085 и 1107 заключают в скобки все тело функции; на древних системах, в которых вообще нет наборов групп, тело функции пустое.
Строки 1086–1088 обрабатывают не-POSIX системы; до компиляции программы механизмом конфигурации определяется
GETGROUPS_NOT_STANDARD
. В этом случае код использует NGROUPS_MAX
, как описано выше. (Даже а 2004 г. такие системы все еще существуют и используются; хотя, слава богу, число их уменьшается.)
Строки 1089–1094 для систем POSIX, причем нулевой параметр
size
используется для получения числа групп.
Строки 1096–1099 осуществляют проверку ошибок. Если возвращаемое значение 0, дополнительных групп нет, поэтому
init_groupset()
просто сразу возвращается.
Наконец, строка 1102 для выделения массива достаточного размера использует
malloc()
(посредством проверяющего ошибки макроса-оболочки, см. раздел 3.2.1.8 «Пример: чтение строк произвольной длины»). Затем строка 1104 заполняет этот массив.
11.3. Проверка для действительного пользователя: access()
В большинстве случаев значения эффективного и действительного UID и GID являются одними и теми же. Таким образом, не имеет значения, что проверка прав доступа к файлу осуществляется по эффективному ID, а не по действительному.
Однако, при написании приложения с setuid или setgid вы можете иногда захотеть проверить, является ли операция, разрешенная для эффективных UID и GID, также разрешенной для действительных UID и GID. В этом заключается задача функции
access()
:
#include /* POSIX */
int access(const char *path, int amode);
Аргумент
path
является путем к файлу для проверки действительных UID и GID. amode
содержит объединение побитовым ИЛИ одного или нескольких из следующих значений:
R_OK
Действительный UID/GID разрешает чтение файла.
W_OK
Действительный UID/GID разрешает запись в файл.
X_OK
Действительный UID/GID разрешает исполнение файла или, в случае каталога, поиск в каталоге.
F_OK
Проверка существования файла.
Проверяется каждый компонент в имени пути, а на некоторых реализациях при проверке для
root access()
может действовать, как если бы был установлен X_OK
, даже если в правах доступа к файлу не установлены биты, разрешающие исполнение. (Странно, но верно: в этом случае предупрежденный вооружен.) В Linux нет такой проблемы.
Если
path
является символической ссылкой, access()
проверяет файл, на который указывает символическая ссылка.
Возвращаемое значение равно 0, если операция для действительных UID и GID разрешена, и -1 в противном случае. Соответственно, если
access()
возвращает -1, программа с setuid может запретить доступ к файлу, с которым в противном случае эффективный UID/GID смог бы работать:
if (access("/some/special/file", R_OK|W_OK) < 0) {
fprintf(stderr, "Sorry: /some/special/file: %s\n",
strerror(errno));
exit(1);
}
По крайней мере для серии ядра Linux 2.4, когда тест X_OK применяется к файловой системе, смонтированной с опцией
noexec
(см. раздел 8.2.1 «Использование опций монтирования»), тест успешно проходится, если права доступа к файлу имеют разрешение на исполнение. Это верно, несмотря на то, что попытка выполнить файл завершилась бы неудачей.
ЗАМЕЧАНИЕ. Хотя использование
access()
перед открытием файла является обычной практикой, существует состояние гонки открываемый файл может быть сброшен при подкачке между проверкой функцией access()
и вызовом open()
. Необходимо осмотрительное программирование, такое, как проверка владельца и прав доступа с помощью stat()
и fstat()
до и после вызовов access()
и open()
.
Например, программа
pathchk
проверяет действительность имен путей. GNU версия использует access()
для проверки того, что компоненты каталога данного пути действительны. Из Coreutils pathchk.c
:
244 /* Возвращает 1, если PATH является годным к использованию
245 каталогом, 0 если нет, 2 если он не существует. */
246
247 static int
248 dir_ok(const char *path)
249 {
250 struct stat stats;
251
252 if (stat (path, &stats)) /* Nonzero return = failure */
253 return 2;
254
255 if (!S_ISDIR(stats.st_mode))
256 {
257 error(0, 0, _("'%s" is not a directory"), path);
258 return 0;
259 }
260
261 /* Используйте access для проверки прав доступа на поиск,
262 поскольку при проверке битов прав доступа st_mode они могут
263 потеряться новыми механизмами управления доступом. Конечно,
264 доступ теряется, если вы используете setuid. */
265 if (access (path, X_OK) != 0)
266 {
267 if (errno == EACCES)
268 error (0, 0, _("directory '%s' is not searchable"), path);
269 else
270 error(0, errno, "%s", path);
271 return 0;
272 }
273
274 return 1;
275 }
Код прост. Строки 252–253 проверяют, существует ли файл. Если
stat()
завершится неудачей, файл не существует. Строки 255–259 удостоверяют, что файл в самом деле является каталогом.
Комментарий в строках 261–264 объясняет использование
access()
. Проверки битов st_mode
недостаточно: файл может находиться в файловой системе, которая смонтирована только для чтения, в удаленной файловой системе или в файловой системе, не принадлежащей Linux или Unix, или у файла могут быть атрибуты, предотвращающие доступ. Таким образом, лишь ядро может в действительности сказать, будет ли работать access
. Строки 265–272 осуществляют проверку, выдавая сообщение об ошибке, определяемое значением errno
(строки 267–270).
11.4. Проверка для эффективного пользователя: euidaccess()
(GLIBC)
GLIBC предоставляет дополнительную функцию, которая работает подобно
access()
, но проверяет в соответствии с эффективными UID, GID и набором групп:
#include /* CLIBC */
int euidaccess(const char *path, int amode);
Аргументы и возвращаемое значение имеют тот же смысл, как для
access()
. Когда равны эффективный и действительный UID и эффективный и действительный GID, euidaccess()
вызывает для осуществления теста access()
. Это имеет то преимущество, что ядро может проверить файловую систему только для чтения или другие условия, которые не отражаются в правах доступа и владении файлами.
В противном случае
euidaccess()
сравнивает значения владельца и группы файла со значениями эффективных UID и GID и набора групп, используя соответствующие биты прав доступа. Этот тест основан на сведениях о файле от stat()
.
Если вы пишете переносимую программу, но предпочитаете использовать этот интерфейс, достаточно просто извлечь исходный файл из архива GLIBC и приспособить его для общего использования.
11.5. Установка дополнительных битов доступа для каталогов
На современных системах setgid и «липкий» биты имеют особое значение при применении к каталогам.
11.5.1. Группа по умолчанию для новых файлов и каталогов
В оригинальной системе Unix, когда
open()
или creat()
создавали новый файл, он получал эффективные UID и GID создавшего их процесса.
V7, BSD вплоть до BSD 4.1 и System V вплоть до Release 3 все трактовали каталоги как файлы. Однако, с добавлением дополнительного набора групп в BSD 4.2 способ создания новых каталогов изменился: новые каталоги наследовали группу родительского каталога. Более того, новые файлы также наследовали ID группы родительского каталога, а не эффективный GID создающего процесса.
Идея, лежащая в основе множества групп и каталогов, которые работают таким способом, была в усилении группового взаимодействия. У каждого проекта организации, использующего систему, была бы отдельная назначенная ему группа. Для каждой такой группы в группе этого проекта был бы каталог верхнего уровня, и все файлы проекта имели бы доступ на чтение и запись (а при необходимости и на исполнение). Вдобавок, новые файлы автоматически получают группу родительского каталога. Состоя одновременно в нескольких группах (наборе групп), пользователь мог бы как угодно перемещаться между проектами с помощью простой команды
cd
, а все файлы и каталоги сохраняли бы свою надлежащую группу.
Что происходит на современных системах? Ну, это еще один из немногих случаев, когда можно поймать двух зайцев. SunOS 4.0 придумал механизм, который был включен в System V Release 4; сегодня он используется по крайней мере в Solaris и GNU/Linux. Эти системы придают биту setgid родительского каталога нового файла или каталога следующее значение:
Бит setgid родительского каталога сброшен
Новые файлы и каталоги получают эффективный GID создающего процесса.
Бит setgid родительского каталога установлен
Новые файлы и каталоги получают GID родительского каталога. Новые каталоги наследуют также установленный бит setgid.
(До SunOS 4.0 бит setgid для каталогов не имел определенного значения.) Следующий сеанс показывает бит setgid в действии:
$ cd /tmp /* Перейти в /tmp */
$ ls -ld . /* Проверить его права доступа */
drwxrwxrwt 8 root root 4096 Oct 16 17:40 .
$ id /* Отметить текущие группы */
uid=2076(arnold) gid=42(devel) groups=19(floppy),42(devel),2076(arnold)
$ mkdir d1 ; ls -ld d1 /* Создать новый каталог */
drwxr-xr-x 2 arnold devel 4096 Oct 16 17:40 d1 /* Эффективный ID группы
наследуется */
$ chgrp arnold d1 /* Сменить группу */
$ chmod g+s d1 /* Добавить бит setgid */
$ ls -ld d1 /* Проверить изменение */
drwxr-sr-x 2 arnold arnold 4096 Oct 16 17:40 d1
$ cd d1 /* Перейти в него */
$ echo this should have group arnold on it > f1 /* создать новый файл */
$ ls -l f1 /* Проверить права доступа */
-rw-r--r-- 1 arnold arnold 36 Oct 16 17:41 f1
/* Унаследовано от родителя */
$ mkdir d2 /* Создать каталог */
$ ls -ld d2 /* Проверить права доступа */
drwxr-sr-x 2 arnold arnold 4096 Oct 16 17:51 d2
/* Группа и setgid унаследованы */
Файловые системы
ext2
и ext3
для GNU/Linux работают указанным способом. Вдобавок они поддерживают специальные опции монтирования grpid
и bsdgroups
, которые делают «использование группы родительского каталога» семантикой по умолчанию. (Два имени означают одно и то же.) Другими словами, когда используются эти опции монтирования, в родительских каталогах не нужно устанавливать свои биты seigid.
Противоположными опциями монтирования являются
nogrpid
и sysvgroups
. Это поведение по умолчанию; однако, бит setgid. если он есть, все равно учитывается. (Здесь также оба имени означают одно и то же.)
POSIX устанавливает, что новые файлы и каталоги наследуют либо эффективный GID создающего процесса, либо группу родительского каталога. Однако, реализации должны предусмотреть способ заставить новые каталоги наследовать группу родительского каталога. Более того, стандарт рекомендует, чтобы приложения не полагались на то или иное поведение, но в случаях, когда это имеет значение, использовали
chown()
для принудительного назначения желательного GID для группы нового файла или каталога.
11.5.2. Каталоги и «липкий» бит
«Шерман, установите машину времени для 1976 г.»
«Липкий» бит ведет начало от версий Unix для PDP-11, он использовался с обычными исполняемыми файлами[119]. Этот бит использовался с программами, которые предназначались для интенсивного использования, такими, как оболочка и редактор. Когда у программы был установлен этот бит, ядро хранило копию исполняемого кода программы на устройстве подкачки, из которого ее можно было быстро загрузить в память для повторного использования. (Загрузка из файловой системы занимает больше времени образ на устройстве подкачки хранился в смежных дисковых блоках, тогда как образ в файловой системе мог быть разбросан по всему диску). Исполняемые образы были «приклеены» к устройству подкачки, отсюда и название.
Таким образом, даже если программа в настоящее время не использовалась, предполагалось, что она вскоре могла быть использована другим пользователем, поэтому она могла быть быстро загружена.
В современных системах значительно более быстрые дисковое оборудование и память, чем в давнишней PDP-11. Они используют также методику, называемую подкачка по требованию, для загрузки в память лишь тех частей исполняемой программы, которые выполняются. Таким образом, сегодня «липкий» бит обычных исполняемых файлов не служит никаким целям и на самом деле ни на что не влияет.
Однако, в разделе 1.1.2 «Каталоги и имена файлов» мы упомянули, что «липкий» бит в каталоге, запись в который в других отношениях разрешена, предотвращает удаление файлов из этого каталога и их переименование любым пользователем, кроме владельца файла или
root
. Вот пример:
$ ls -ld /tmp /* Показать права доступа к /tmp */
drwxrwxrwt 19 root root 4096 Oct 20 14:04 /tmp
$ cd /tmp /* Перейти туда */
$ echo this is my file > arnolds-file /* Создать файл */
$ ls -l arnolds-file /* Показать его права доступа */
-rw-r--r-- 1 arnold devel 16 Oct 20 14:14 arnolds-file
$ su - miriam /* Смена пользователя */
Password:
$ cd /tmp /* Перейти в /tmp */
$ rm arnolds-file /* Попытка удаления файла */
rm: remove write-protected regular file 'arnolds-file'? y
/* rm предупреждает */
rm: cannot remove 'arnolds-file': Operation not permitted
/* Ядро запрещает удаление */
Основным назначением этой особенности является как раз использование в таких каталогах, как
/tmp
, куда хотят помещать свои файлы множество пользователей. С одной стороны, каталог должен иметь права записи для всех, чтобы каждый мог создавать там свои файлы. С другой стороны, раз запись разрешена для всех, любой пользователь может удалять файлы всех остальных пользователей! «Липкий» бит каталога красиво решает эту проблему. Для добавления к файлу или каталогу «липкого» бита используйте 'chmod +t
':
$ mkdir mytmp /* Создать каталог */
$ chmod a+wxt mytmp /* Добавить права записи для всех и «липкий» бит */
$ ls -ld mytmp /* Проверить результат */
drwxrwxrwt 2 arnold devel 4096 Oct 20 14:23 mytmp
В заключение, обратите внимание, что владелец каталога также может удалить файлы, даже если они не принадлежат ему.
11.6. Установка действительных и эффективных ID
Все становится интереснее, когда процессу приходится менять значения UID и GID. Установка набора групп проста. Изменение значений действительных и эффективных UID и GID сложнее.
11.6.1. Изменение набора групп
Функция
setgroups()
устанавливает новый набор групп:
#include /* Common */
#include
#include
int setgroups(size_t size, const gid_t *list);
Параметр
size
указывает, сколько элементов в массиве list
. Возвращаемое значение равно 0, если все было нормально, и -1 с установленным errno в противном случае.
В отличие от функций для манипулирования значениями действительных и эффективных UID и GID, эту функцию может вызвать лишь процесс, действующий как
root
. Это один пример того, что POSIX называет привилегированной операцией; сама она как таковая не стандартизуется POSIX.
setgroups()
используется любой программой, которая осуществляет регистрацию в системе, такой как /bin/login
для регистрации в консоли и /bin/sshd
для удаленной регистрации с помощью ssh
.
11.6.2. Изменение действительного и эффективного ID
Работа с двумя различными ID пользователей представляет для программиста приложения проблему. Могут быть вещи, которые программе нужно сделать, работая с эффективным UID, а другие вещи — работая с действительным UID.
Например, до того, как в системах Unix появилось управление заданиями, многие программы предоставляли переходы в оболочку, т.е. способ запуска команды или интерактивной оболочки из текущей программы. Хорошим примером этого является редактор
ed
: набор командной строки, начинающейся с '!
', запускает оставшуюся часть строки в качестве команды оболочки. Набрав '!sh
', вы получаете интерактивную оболочку. (Это работает до сих пор — попробуйте!) Предположим, описанная ранее гипотетическая игровая программа также предоставляет переход в оболочку: она должна быть запущена от имени действительного пользователя, а не эффективного. В противном случае, редактирование файла счета или многие гораздо худшие вещи становятся для игрока тривиальной задачей!
Таким образом, имеется явная потребность в возможности замены эффективного UID действительным UID. Более того, полезна возможность обратного переключения эффективного UID на первоначальный. (В этом причина необходимости наличия сохраненного set-user ID; появляется возможность восстановления первоначальных привилегий, которые были у процесса при его запуске.)
Как и для множества Unix API, различные системы решили проблему разными способами, иногда с использованием одного и того же API, но с другой семантикой, а иногда введением другого API. Погружение в исторические подробности годится лишь для создания головной боли, поэтому мы не будем с этим беспокоиться. Вместо этого мы рассмотрим, что предоставляет POSIX и как работает каждый API. Более того, наше обсуждение фокусируется на значениях действительных и эффективных UID; значения GID работают аналогичным образом, поэтому мы не будем хлопотать с повторением подробностей для этих системных вызовов. Функции следующие:
#include /* POSIX */
#include
int seteuid(uid_t euid); /* Установка эффективного ID */
int setegid(gid_t egid);
int setuid(uid_t uid);
/* Установка эффективного ID, root устанавливает все */
int setgid(gid_t gid);
int setreuid(uid_t ruid, uid_t euid);
/* Совместимость с BSD, устанавливаются оба */
int setregid(gid_t rgid, gid_t egid);
Есть три набора функций. Первые два были созданы POSIX:
int seteuid(uid_t euid)
Эта функция устанавливает лишь эффективный UID. Обычный пользователь (не
root
) может установить в качестве ID лишь в значения действительного, эффективного или сохраненного set-user ID. Приложения, которые будут переключать эффективный UID. должны использовать исключительно эту функцию.
Процесс с эффективным UID, равным нулю, может установить в качестве эффективного UID любое значение. Поскольку в качестве значения эффективного UID можно установить также сохраненный set-user ID, процесс может восстановить свои привилегии root с помощью другого вызова
seteuid()
.
int setegid(gid_t egid)
Эта функция делает для эффективного ID группы то, что
seteuid()
делает для эффективного ID пользователя.
Следующий набор функций предлагает первоначальный API Unix для изменения действительных и эффективных UID и GID. В модели POSIX эти функции являются тем. что должна использовать программа с setuid-root для постоянного изменения действительного или эффективного UID:
int setuid(uid_t uid)
Для обычного пользователя эта функция также устанавливает лишь эффективный UID. Как и для
seteuid()
, значением эффективного UID может быть любое из текущих значений действительного, эффективного иди сохраненного set-user ID. Изменение не постоянно; эффективный UID может быть изменен последующим вызовом на другое значение (из того же исходного набора).
Однако, для
root
эта функция устанавливает в данное значение все три значения для действительного, эффективного и сохраненного set-user ID. Более того, изменение постоянно; прежнее ID нельзя восстановить. (Это имеет смысл: раз изменился сохраненный set-user ID, нет другого ID для восстановления.)
int setgid(gid_t gid)
Эта функция делает для эффективного ID группы то же, что
setuid()
делает для эффективного ID пользователя. Используется то же разграничение между обычными пользователями и root
.
ЗАМЕЧАНИЕ. Возможность изменения ID группы зависит от эффективного ID пользователя. Эффективный GID, равный 0, не имеет особых привилегий.
Наконец, POSIX представляет для исторической совместимости две функции из BSD 4.2. В новом коде их лучше не использовать. Однако, поскольку вы, вероятно, увидите использующий эти функции старый код, мы их здесь опишем.
int setreuid(uid_t ruid, uid_t euid)
Устанавливает данные значения в качестве действительного и эффективного UID. Значение -1 для
ruid
или euid
оставляет соответствующие ID без изменения. (Это похоже на chown()
; см. раздел 5.5.1 «Смена владельца файла: chown()
, fchown()
и lchown()
».)
root
может устанавливать в качестве действительного и эффективного ID любое значение. В соответствии с POSIX пользователи, не являющиеся root
, могут изменять лишь эффективный ID; то, что случится, если обычный пользователь попытается изменить действительный UID, «не определено». Однако, справочная страница GNU/Linux setreuid(2) разъясняет поведение Linux, в качестве действительного UID может быть установлено значение действительного или эффективного UID, а в качестве эффективного UID может быть значение действительного, эффективного или сохраненного set-user ID. (Для других систем см. справочную страницу setreuid(2).)
int setregid(gid_t rgid, gid_t egid)
Делает для действительных и эффективных ID групп то же, что
setreuid()
делает для действительных и эффективных ID пользователя. Используется то же разграничение между обычными пользователями и root
.
Сохраненный set-user ID в модели BSD не существует, поэтому лежащей в основе
setreuid()
и setregid()
идеей было упростить переключение между действительным и эффективным ID:
setreuid(geteuid(), getuid()); /* обмен действительным и эффективным */
Однако, с принятием POSIX модели сохранения set-user ID и функций
seteuid()
и setegid()
функции BSD не следует использовать в новом коде. Даже документация BSD 4.4 помечает эти функции как устаревшие, рекомендуя вместо них seteuid()
/setuid()
и setegid()
/setgid()
.
11.6.3. Использование битов setuid и setgid
Есть важные случаи, в которых действующая как
root
программа должна безвозвратно изменить все три значения действительного, эффективного и сохраненного set-user ID на ID обычного пользователя. Наиболее очевидным случаем является программа login
, которую вы используете (либо непосредственно, либо удаленно) каждый раз при регистрации в системе GNU/Linux или Unix. Имеется иерархия программ, как очерчено на рис. 11.1.
Рис. 11.1. От
init
через getty
через login
к shell
Код для
login
слишком сложен, чтобы показать здесь, поскольку он имеет дело с рядом задач, не имеющих отношения к текущему обсуждению. Но мы можем очертить шаги, которые происходят во время регистрации, следующим образом:
1.
init
является самым первым процессом. Его PID равен 1. Все другие процессы являются его потомками. Ядро вручную создает процесс 1 во время загрузки и запускает в нем init
. Он действует с действительным и эффективным UID, равными нулю, т.е. как root
.
2.
init
читает /etc/inittab
, который, помимо прочих вещей, сообщает init
о том, на каких устройствах он должен запустить процесс getty
. Для каждого такого устройства (такого, как консоль, последовательные терминалы или виртуальные консоли в системе GNU/Linux) init
порождает новый процесс. Этот новый процесс использует затем exec()
для запуска getty
(от «get tty» («получить tty», т.е. терминал)). На многих системах GNU/Linux эта команда называется mingetty
. Программа открывает устройство, сбрасывает его состояние и выводит приглашение 'login:
'.
3. По получении регистрационного имени
getty
выполняет login
. Программа login
ищет имя пользователя в файле паролей, запрашивает пароль и проверяет его. Если пароль подходит, процесс login
продолжается.
4.
login
изменяет домашний каталог пользователя, устанавливает начальное окружение, а затем устанавливает начальный набор открытых файлов. Он закрывает дескрипторы файлов, открывает терминал и использует dup()
для копирования дескрипторов файла терминала в 0, 1 и 2. Вот откуда происходят дескрипторы уже открытых файлов стандартного ввода, стандартного вывода и стандартной ошибки.
5. Затем
login
использует setgroups()
для установки дополнительного набора групп, setgid()
для установки значений действительного, эффективного и сохраненного set-group ID в соответствующее значение группы пользователя, и наконец, setuid()
для установки всех трех значений действительного, эффективного и сохраненного set-user ID в соответствующие значения для регистрирующегося пользователя. Обратите внимание, что вызов setuid()
должен быть последним для того, чтобы другие два вызова завершились успешно.
6. Наконец,
login
вызывает зарегистрированную оболочку пользователя. Оболочки в стиле Борна после этого читают файлы /etc/profile
и $HOME/.profile
, если они существуют. Затем оболочка выводит приглашение.
Обратите внимание, как один процесс меняет свою сущность от системного процесса до процесса пользователя. Каждый потомок
init
начинается как копия init
. Используя exec()
, тот же самый процесс выполняет различные задания. Вызвав setuid()
для перехода от root
к обычному пользователю, процесс в конечном счете поступает непосредственно для работы пользователя. Когда вы выходите из оболочки (посредством CTRL-D или exit
), процесс попросту завершается. Затем init
возобновляет цикл, порождая новый getty
, который выводит новое приглашение 'login:
'.
ЗАМЕЧАНИЕ. Открытые файлы остаются открытыми и доступными для использования, даже после изменения процессом своих UID или GID. Таким образом, программы с setuid должны заранее открыть все нужные файлы, изменить их ID на ID действительного пользователя и продолжить оставшуюся часть работы без дополнительных привилегий
В табл. 11.1 приведена сводка шести стандартных функций для манипулирования значениями UID и GID.
Таблица 11.1. Сводка API для установки действительных и эффективных ID[120]
Функция
Устанавливает
Постоянно
Обычный пользователь
Root
seteuid()
E
Нет
Из R, E, S
Любое
setegid()
E
Нет
Из R, E, S
Любое
setuid()
Root: R,E,S Другие: E
Root: да Другие: нет
Из R, E
Любое
setgid()
Root: R,E,S Другие: E
Root: да Другие: нет
Из R, E
Любое
setreuid()
E, может установить R
Нет
Из R, E
Любое
setregid()
E, может установить R
Нет
Из R, E
Любое
11.7. Работа со всеми тремя ID: getresuid()
и setresuid()
(Linux)
Linux предоставляет дополнительные системные вызовы, посредством которых вы можете непосредственно работать с действительными, эффективными и сохраненными ID пользователя и группы:
#include /* Linux */
#include
int getresuid(uid_t *ruid, uid_t *euid, uid_t *suid);
int getresgid(gid_t *rgid, gid_t *egid, gid_t *sgid);
int setresuid(uid_t ruid, uid_t euid, uid_t suid);
int setresgid(gid_t rgid, gid_t egid, gid_t sgid);
Функции следующие:
int getresuid(uid_t *ruid, uid_t *euid, uid_t *suid)
Получает значения действительного, эффективного и сохраненного set-user ID. Возвращаемое значение 0 в случае успеха и -1 при ошибке,
errno
указывает проблему.
int getresgid(gid_t *rgid, gid_t *egid, gid_t *sgid)
Получает значения действительного, эффективного и сохраненного set-group ID. Возвращаемое значение 0 в случае успеха и -1 при ошибке,
errno
обозначает проблему.
int setresuid(uid_t ruid, uid_t euid, uid_t suid)
Устанавливает значения действительного, эффективного и сохраненного set-user ID соответственно. Когда значение параметра равно -1, соответствующий UID остается без изменения.
Когда процесс действует как
root
, параметрами могут быть любые произвольные значения. Однако, использование ненулевого значения для euid
вызывает постоянную, безвозвратную утерю привилегии root
). В противном случае параметры должны быть одним из значений действительного, эффективного или сохраненного set-user ID.
int setresgid(gid_t rgid, gid_t egid, gid_t sgid)
Устанавливает значения действительного, эффективного и сохраненного set-group ID соответственно. Когда значение параметра равно -1, соответствующий GID остается без изменений.
Эта функция аналогична
setresuid()
.
Функции
setresuid()
и setresgid()
особенно ценны, поскольку их семантика ясно определена. Программист точно знает, каким может быть результат их вызова.
Более того, вызовы являются операциями типа «все или ничего»: они либо полностью успешны в осуществлении нужного изменения, либо терпят полную неудачу, оставляя текущее состояние как есть. Это повышает надежность, поскольку, опять-таки можно быть точно уверенным в том, что случилось.
11.8. Пересечение минного поля безопасности: setuid root
Настоящие минные поля трудно, но не невозможно перейти. Однако, это не является чем-то, что можно сделать легко, без тренировки или опыта
Точно также написание программ, которые используют setuid
root
, является трудной задачей. Имеется много, очень много проблем, о которых нужно знать, и почти все может иметь неожиданные последствия в плане безопасности. Такая попытка должна предприниматься очень осторожно.
В частности, стоит специально изучить проблемы безопасности Linux/Unix и потратить время на обучение написанию программ setuid root. Если вы сразу нырнете в эту проблему, прочитав лишь эту книгу и ничего более, можно быть уверенным, что ваша система будет взломана, легко и сразу. Маловероятно, что вы или ваши клиенты будут довольны.
Вот несколько руководящих принципов:
• Как можно меньше действуйте в качестве
root
. Скупо используйте свои чрезвычайные полномочия, лишь тогда, когда это абсолютно необходимо
• Соответствующим образом проектируйте свою программу. Разделите программу на составные части таким образом, чтобы все операции
root
были выполнены заранее, а оставшаяся программа работала в качестве обычного пользователя.
• При изменении или сбрасывании привилегий используйте
setresuid()
, если она у вас есть. В противном случае используйте setreuid(),
поскольку у этих функций самая чистая семантика. Используйте setuid()
, лишь когда вы хотите сделать постоянное изменение.
• Переходите от
root
к обычному пользователю в соответствующем порядке: сначала установите набор групп и значения GID, затем значения UID. Будьте особенно осторожны с fork()
и exec()
; действительные и эффективные UID при их вызове не изменяются, если вы не измените их явным образом.
• Рассмотрите использование прав доступа setgid и особой группы для вашего приложения. Если это будет работать, это убережет вас от большой головной боли.
• Рассмотрите отказ от наследуемого окружения. Если вам нужно сохранить некоторые переменные окружения, сохраните как можно меньше. Убедитесь в предоставлении подходящих значений для переменных окружения
PATH
и IFS
.
• Избегайте
execlp()
и execvp()
, которые зависят от значения переменной окружения PATH
(хотя это менее проблематично, если вы сами восстанавливаете PATH
).
Это просто некоторые из множества тактик по пересечению опасной зоны, известной своими подвохами, минами-ловушками и фугасами. Ссылки на другие источники информации см. в следующем разделе.
11.9. Рекомендуемая литература
Безопасность Unix (а следовательно, и GNU/Linux) является темой, требующей знаний и опыта для того, чтобы справиться с ней должным образом. В Эпоху Интернета она стала лишь труднее, не проще.
1. Practical UNIX & Internet Security, 3rd edition, by Simson Garfinkel, Gene Spafford, and Alan Schwartz, O'Reilly & Associates, Sebastopol, CA, USA, 2003. ISBN: 0-596-00323-4.
Это стандартная книга по безопасности Unix.
2. Building Secure Software. How to Avoid Security Problems the Right Way, by John Viega and Gary McGraw. Addison-Wesley, Reading, Massachusetts, USA, 2001. ISBN: 0-201-72152-X.
Это хорошая книга по написанию безопасного программного обеспечения, она включает проблемы setuid. Предполагается, что вы знакомы с основными API Linux/Unix; к моменту прочтения данной книги вы должны быть готовы к ее прочтению.
3. "Setuid Demystified," by Hao Chen, David Wagner, and Drew Dean. Proceedings of the 11th USENIX Security Symposium, August 5–9, 2002 http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf.
Гарфинкель, Спаффорд и Шварц (Garfinkel, Spafford, Schwartz) рекомендуют прочтение этого материала «до того, как вы даже подумаете о написании кода, который пытается сохранять и восстанавливать привилегии». Мы всецело согласны с ними.
11.10. Резюме
• Использование значений ID пользователя и группы (UID и GID) для идентификации файлов и процессов — вот что превращает Linux и Unix в многопользовательские системы. Процессы имеют значения как действительных, так и эффективных UID и GID, а также набор дополнительных групп. Обычно именно эффективный UID определяет, как один процесс может повлиять на другой, и эффективные UID, GID и набор групп проверяются на соответствие с правами доступа к файлу. Пользователи с эффективным UID, равным нулю, известные как
root
или суперпользователи, могут делать все, что захотят; система не использует для такого пользователя проверку прав доступа.
• Концепции сохраненных set-user ID и set-group ID пришли из System V и были приняты POSIX с полной поддержкой в GNU/Linux. Наличие этих отдельных значений ID дает возможность легко и безошибочно переключать при необходимости действительные и эффективные UID (и GID).
• Программы setuid и setgid создают процессы, в которых действительные и эффективные ID различаются. Программы как таковые помечаются дополнительными битами прав доступа к файлу. Биты setuid и setgid должны быть добавлены к файлу после его создания.
•
getuid()
и geteuid()
получают значения действительного и эффективного UID соответственно, a getgid()
и getegid()
получают значения действительного и эффективного GID соответственно, getgroups()
получает набор дополнительных групп, а в среде POSIX может запросить у системы, сколько членов содержит набор групп.
• Функция
access()
осуществляет проверку прав доступа к файлу для действительного пользователя, давая возможность программе setuid проверить полномочия реального пользователя. Обратите внимание, что часто проверка возвращаемых stat()
сведений может не представить полной картины при условии, что файл может находиться на не родной или сетевой файловой системе.
• Функция GLIBC
euidaccess()
сходна с access()
, но осуществляет проверку на основе значений эффективных UID и GID.
• «Липкий» бит и бит setgid при использовании с каталогами привносят дополнительную семантику. Когда для каталога установлен бит setgid, новые файлы в этом каталоге наследуют группу этого каталога. Новые каталоги делают то же самое, они также автоматически наследуют установку бита setgid. Без установленного бита setgid новые файлы и каталоги получают эффективный GID создающего их процесса. «Липкий» бит, установленный для каталогов, в которые в других отношениях разрешена запись, ограничивает право на удаление файла владельцем файла, владельцем каталога и
root
.
• Набор групп изменяется с помощью
setgroups()
. Эта функция не стандартизована POSIX, но существует на всех современных системах Unix. Ее может использовать лишь root
.
• Изменение UID и GID довольно сложно. Семантика различных системных вызовов с течением времени изменилась. Новые приложения, которые будут изменять лишь свои эффективные UID/GID, должны использовать
seteuid()
и setegid()
. Приложения, не действующие от имени root
, могут также устанавливать свои эффективные ID с помощью setuid()
и setgid()
. Вызовы setreuid()
и setregid()
от BSD были предназначены для обмена значениями UID и GID; их использование в новых программах не рекомендуется.
• Приложения, действующие как
root
, могут перманентно заменить значения действительного, эффективного и сохраненного ID с помощью setuid()
и setgid()
. Одним из таких примеров является login
, которая должна превратиться из программы, выполняющейся как root
в не непривилегированную зарегистрированную оболочку, выполняющуюся от имени обычного пользователя.
• Функции Linux
setresuid()
и setresgid()
следует использовать всегда, когда они доступны, поскольку они обеспечивают самое чистое и наиболее надежное поведение
• Написание приложений setuid-
root
не является задачей для новичка. Если вам нужно сделать такую вещь, сначала специально изучите проблемы безопасности. Для этого можно воспользоваться приведенными выше превосходными источниками.
Упражнения
1. Напишите простую версию команды
id
. Ее назначением является отображение в стандартный вывод ID пользователя и группы с указанием имен групп. Когда эффективный и действительный ID различаются, выводятся оба. Например:
$ id
uid=2076(arnold) gid=42(devel) groups=19(floppy), 42(devel), 2076(arnold)
Ее использование:
id [ пользователь ]
id -G [ -nr ] [ пользователь ]
id -g [ -nr ] [ пользователь ]
id -u [ -nr ] [ пользователь ]
При указанном пользователе выводятся сведения об этом пользователе; в противном случае
id
выводит сведения о пользователе, вызвавшем программу. Опции следующие:
-G
Выводит все значения групп в виде чисел, без имен.
-n
Выводит лишь имена, без числовых значений. Применяется с значениями пользователя и группы.
-g
Выводит лишь эффективный GID.
-u
Выводит лишь эффективный UID.
2. Напишите простую программу с именем
sume
и установите setuid на себя. Она должна запрашивать пароль (см. getpass(3)), который в целях данного примера может быть жестко вшит в исходный код программы. Если лицо, запустившее программу, вводит пароль правильно, sume
должна выполнить exec оболочки. Попросите другого пользователя помочь вам ее протестировать.
3. Как вы относитесь к тому, чтобы сделать
sume
доступной для ваших друзей? Для ваших приятелей студентов или сотрудников? Для каждого пользователя на вашей системе?
Linux, вслед за Unix, является многопользовательской системой. В отличие от большинства операционных систем для персональных компьютеров,[114] в которых имеется лишь один пользователь и в которых, кто бы ни находился перед компьютером, он имеет полный контроль, Linux и Unix различают файлы и процессы по владельцам и группам, которым они принадлежат. В данной главе мы исследуем проверку прав доступа и рассмотрим API для получения и установки идентификаторов владельцев и групп.
11.1. Проверка прав доступа
Как мы видели в разделе 5.4.2 «Получение информации о файлах», файловая система хранит идентификаторы владельца и группы файла в виде числовых значений; это типы
uid_tgid_tУ каждого процесса есть несколько связанных с ним идентификаторов пользователя и группы. Для проверки прав доступа в качестве упрощения используется один определенный UID и GID; когда UID процесса совпадает с UID файла, биты прав доступа пользователя файла диктуют, что может сделать процесс с файлом. Если они не совпадают, система проверяет GID процесса с GID файла; при совпадении используются права доступа группы; в противном случае, используются права доступа для «остальных».
Помимо файлов, UID определяет, как один процесс может повлиять на другой путем посылки сигналов. Сигналы описаны в главе 10 «Сигналы».
Наконец, особым случаем является суперпользователь,
rootroot11.1.1. Действительные и эффективные ID
Номера UID и GID подобны персональным удостоверениям личности. Иногда вам может понадобиться более одного удостоверяющего документа. Например, у вас могут быть водительские права или правительственное удостоверение личности[115]. Вдобавок, ваш университет или компания могли выдать вам свои удостоверения личности. То же самое относится и к процессам; они имеют при себе множество следующих номеров UID и GID:
Действительный ID пользователя
UID пользователя, породившего процесс.
Эффективный ID пользователя
UID, использующийся при большинстве проверок прав доступа. В большинстве случаев эффективный и действительный UID являются одним и тем же. Эффективный UID может отличаться от действительного при запуске, если установлен бит setuid файла исполняемой программы и файл не принадлежит пользователю, запускающему программу. (Вскоре будут дополнительные сведения.)
Сохраненный set-user ID
Первоначальный эффективный UID при запуске программы (после выполнения exec.) Имеет значение при проверке прав доступа, когда процессу нужно менять действительный и эффективный UID в ходе работы. Эта концепция пришла из System V.
Действительный ID группы
GID пользователя, создавшего процесс, аналогично действительному UID.
Эффективный ID группы
GID, использующийся для проверки прав доступа, аналогично эффективному GID.
Сохраненный set-group ID
Первоначальный эффективный GID при запуске программы, аналогично сохраненному set-user ID.
Набор дополнительных групп
4.2 BSD ввело понятие набора групп. Помимо действительного и эффективного GID. у каждого процесса есть некоторый набор дополнительных групп, которым он принадлежит в одно и то же время. Таким образом, когда проверка прав доступа осуществляется для группы файла, ядро проверяет не только эффективный GID, но также и все GID в наборе групп.
Каждый процесс может получить все из этих значений. Обычный (не принадлежащий суперпользователю) процесс может переключать свои действительные и эффективные ID пользователя и группы. Процесс
root11.1.2. Биты Setuid и Setgid
Биты setuid и setgid[116] в правах доступа к файлу заставляют процесс принять эффективный UID или GID, который отличается от действительного. Эти биты накладываются на файл вручную с помощью команды
chmod$ chmod u+s myprogram /* Добавить бит setuid */$ chmod g+s myprogram /* Добавить бит setgid */$ ls -l myprogram-rwsr-sr-x 1 arnold devel 4573 Oct 9 18:17 myprogramНаличие символа s в месте, где обычно находится символ x, указывает на присутствие битов setuid/setgid.
Как упоминалось в разделе 8.2.1 «Использование опций монтирования», опция
nosuidrootnosuidrootКаноническим (и возможно, злоупотребляемым) примером программы с setuid является игровая программа. Представьте, что вы написали по-настоящему крутую игру и хотите позволить пользователям системы играть в нее. Игра содержит файл счета, в котором перечислены высшие достижения.
Если вы не являетесь системным администратором, вы не можете создать отдельную группу только для тех пользователей, которым разрешено играть в игру и тем самым записывать в файл счета. Но если вы сделаете файл доступным для записи любому, чтобы каждый смог поиграть в игру, тогда каждый сможет также сжульничать и поместить наверх любое имя.
Однако, заставив программу устанавливать setuid на вас, пользователи, запускающие игру, получат ваш UID в качестве своего эффективного UID. Игровая программа сможет при этом открывать и обновлять файл счета по мере необходимости, но произвольные пользователи не смогут прийти и отредактировать его. (Вы подвергаете себя также большинству опасностей при программировании setuid; например, если в игровой программе есть дыра, которую можно использовать для запуска оболочки, действующей от вашего имени, все ваши файлы оказываются доступными для удаления или изменения. Это действительно устрашающая мысль.)
Та же логика применяется к программам setgid, хотя на практике программы с setgid используются гораздо реже, чем с setuid (Это также плохо; многие вещи, которые делаются программами с setuid
root11.2. Получение ID пользователя и группы
Получение от системы сведений о UID и GID просто. Функции следующие:
#include /* POSIX */ uid_t getuid(void); /* Действительный и эффективный UID */uid_t geteuid(void);gid_t getgid(void); /* Действительный и эффективный GID */gid_t getegid(void);int getgroups(int size, gid_t list[]); /* Список дополнительных групп*/Функции:
uid_t getuid(void)Возвращает действительный UID.
uid_t geteuid(void)Возвращает эффективный UID.
gid_t getgid(void)Возвращает действительный GID.
gid_t getegid(void)Возвращает эффективный GID.
int getgroups(int size, gid_t list[])Заполняет до
sizelistgetgroups()NGROUPS_MAXlistВозможно, вы заметили, что для получения сохраненных значений set-user ID или set-group ID нет вызовов. Это просто первоначальные значения эффективных UID и GID. Таким образом, для получения шести значений в начале программы вы можете использовать код наподобие этого:
uid_t ruid, euid, saved_uid;gid_t rgid, egid, saved_gid;int main(int argc, char **argv) { ruid = getuid(); euid = saved_uid = geteuid(); rgid = getgid(); egid = saved_gid = getegid(); /* ...оставшаяся программа... */}Вот пример получения набора групп. В качестве расширения
gawkawkmain.cgawk1080 /* init_groupset --- инициализация набора групп */10811082 static void1083 init_groupset()1084 {1085 #if defined(HAVE_GETGROUPS) && defined(NGROUPS_MAX) && NGROUPS_MAX > 01086 #ifdef GETGROUPS_NOT_STANDARD1087 /* Для систем, которые не отвечают стандарту, используйте старый способ */1088 ngroups = NGROUPS_MAX;1089 #else1090 /*1091 * Если оба аргумента при вызове равны 0, возвращаемое1092 * значение является общим числом групп.1093 */1094 ngroups = getgroups(0, NULL);1095 #endif1096 if (ngroups == -1)1097 fatal(_("could not find groups: %s"), strerror(errno));1098 else if (ngroups == 0)1099 return;11001101 /* заполнить группы */1102 emalloc(groupset, GETGROUPS_T*, ngroups * sizeof(GETGROUPS_T), "init_groupset");11031104 ngroups = getgroups(ngroups, groupset);1105 if (ngroups == -1)1106 fatal(_("could not find groups: %s"), strerror(errno));1107 #endif1108 }Переменные
ngroupsgroupsetGETGROUPS_Tgid_tintСтроки 1085 и 1107 заключают в скобки все тело функции; на древних системах, в которых вообще нет наборов групп, тело функции пустое.
Строки 1086–1088 обрабатывают не-POSIX системы; до компиляции программы механизмом конфигурации определяется
GETGROUPS_NOT_STANDARDNGROUPS_MAXСтроки 1089–1094 для систем POSIX, причем нулевой параметр
sizeСтроки 1096–1099 осуществляют проверку ошибок. Если возвращаемое значение 0, дополнительных групп нет, поэтому
init_groupset()Наконец, строка 1102 для выделения массива достаточного размера использует
malloc()
11.3. Проверка для действительного пользователя: access()
access()В большинстве случаев значения эффективного и действительного UID и GID являются одними и теми же. Таким образом, не имеет значения, что проверка прав доступа к файлу осуществляется по эффективному ID, а не по действительному.
Однако, при написании приложения с setuid или setgid вы можете иногда захотеть проверить, является ли операция, разрешенная для эффективных UID и GID, также разрешенной для действительных UID и GID. В этом заключается задача функции
access()#include /* POSIX */ int access(const char *path, int amode);Аргумент
pathamodeR_OK W_OK X_OK F_OK Проверяется каждый компонент в имени пути, а на некоторых реализациях при проверке для
root access()X_OKЕсли
pathaccess()Возвращаемое значение равно 0, если операция для действительных UID и GID разрешена, и -1 в противном случае. Соответственно, если
access()if (access("/some/special/file", R_OK|W_OK) < 0) { fprintf(stderr, "Sorry: /some/special/file: %s\n", strerror(errno)); exit(1);}По крайней мере для серии ядра Linux 2.4, когда тест X_OK применяется к файловой системе, смонтированной с опцией
noexecЗАМЕЧАНИЕ. Хотя использование
access()access()open()stat()fstat()access()open()Например, программа
pathchkaccess()pathchk.c244 /* Возвращает 1, если PATH является годным к использованию245 каталогом, 0 если нет, 2 если он не существует. */246247 static int248 dir_ok(const char *path)249 {250 struct stat stats;251252 if (stat (path, &stats)) /* Nonzero return = failure */253 return 2;254255 if (!S_ISDIR(stats.st_mode))256 {257 error(0, 0, _("'%s" is not a directory"), path);258 return 0;259 }260261 /* Используйте access для проверки прав доступа на поиск,262 поскольку при проверке битов прав доступа st_mode они могут263 потеряться новыми механизмами управления доступом. Конечно,264 доступ теряется, если вы используете setuid. */265 if (access (path, X_OK) != 0)266 {267 if (errno == EACCES)268 error (0, 0, _("directory '%s' is not searchable"), path);269 else270 error(0, errno, "%s", path);271 return 0;272 }273274 return 1;275 }Код прост. Строки 252–253 проверяют, существует ли файл. Если
stat()Комментарий в строках 261–264 объясняет использование
access()st_modeaccesserrno
11.4. Проверка для эффективного пользователя: euidaccess()
(GLIBC)
euidaccess()GLIBC предоставляет дополнительную функцию, которая работает подобно
access()#include /* CLIBC */ int euidaccess(const char *path, int amode);Аргументы и возвращаемое значение имеют тот же смысл, как для
access()euidaccess()access()В противном случае
euidaccess()stat()Если вы пишете переносимую программу, но предпочитаете использовать этот интерфейс, достаточно просто извлечь исходный файл из архива GLIBC и приспособить его для общего использования.
11.5. Установка дополнительных битов доступа для каталогов
На современных системах setgid и «липкий» биты имеют особое значение при применении к каталогам.
11.5.1. Группа по умолчанию для новых файлов и каталогов
В оригинальной системе Unix, когда
open()creat()V7, BSD вплоть до BSD 4.1 и System V вплоть до Release 3 все трактовали каталоги как файлы. Однако, с добавлением дополнительного набора групп в BSD 4.2 способ создания новых каталогов изменился: новые каталоги наследовали группу родительского каталога. Более того, новые файлы также наследовали ID группы родительского каталога, а не эффективный GID создающего процесса.
Идея, лежащая в основе множества групп и каталогов, которые работают таким способом, была в усилении группового взаимодействия. У каждого проекта организации, использующего систему, была бы отдельная назначенная ему группа. Для каждой такой группы в группе этого проекта был бы каталог верхнего уровня, и все файлы проекта имели бы доступ на чтение и запись (а при необходимости и на исполнение). Вдобавок, новые файлы автоматически получают группу родительского каталога. Состоя одновременно в нескольких группах (наборе групп), пользователь мог бы как угодно перемещаться между проектами с помощью простой команды
cdЧто происходит на современных системах? Ну, это еще один из немногих случаев, когда можно поймать двух зайцев. SunOS 4.0 придумал механизм, который был включен в System V Release 4; сегодня он используется по крайней мере в Solaris и GNU/Linux. Эти системы придают биту setgid родительского каталога нового файла или каталога следующее значение:
Бит setgid родительского каталога сброшен
Новые файлы и каталоги получают эффективный GID создающего процесса.
Бит setgid родительского каталога установлен
Новые файлы и каталоги получают GID родительского каталога. Новые каталоги наследуют также установленный бит setgid.
(До SunOS 4.0 бит setgid для каталогов не имел определенного значения.) Следующий сеанс показывает бит setgid в действии:
$ cd /tmp /* Перейти в /tmp */$ ls -ld . /* Проверить его права доступа */drwxrwxrwt 8 root root 4096 Oct 16 17:40 .$ id /* Отметить текущие группы */uid=2076(arnold) gid=42(devel) groups=19(floppy),42(devel),2076(arnold)$ mkdir d1 ; ls -ld d1 /* Создать новый каталог */drwxr-xr-x 2 arnold devel 4096 Oct 16 17:40 d1 /* Эффективный ID группы наследуется */$ chgrp arnold d1 /* Сменить группу */$ chmod g+s d1 /* Добавить бит setgid */$ ls -ld d1 /* Проверить изменение */drwxr-sr-x 2 arnold arnold 4096 Oct 16 17:40 d1$ cd d1 /* Перейти в него */$ echo this should have group arnold on it > f1 /* создать новый файл */$ ls -l f1 /* Проверить права доступа */-rw-r--r-- 1 arnold arnold 36 Oct 16 17:41 f1 /* Унаследовано от родителя */$ mkdir d2 /* Создать каталог */$ ls -ld d2 /* Проверить права доступа */drwxr-sr-x 2 arnold arnold 4096 Oct 16 17:51 d2 /* Группа и setgid унаследованы */Файловые системы
ext2ext3grpidbsdgroupsПротивоположными опциями монтирования являются
nogrpidsysvgroupsPOSIX устанавливает, что новые файлы и каталоги наследуют либо эффективный GID создающего процесса, либо группу родительского каталога. Однако, реализации должны предусмотреть способ заставить новые каталоги наследовать группу родительского каталога. Более того, стандарт рекомендует, чтобы приложения не полагались на то или иное поведение, но в случаях, когда это имеет значение, использовали
chown()
11.5.2. Каталоги и «липкий» бит
«Шерман, установите машину времени для 1976 г.»
«Шерман, установите машину времени для 1976 г.»
«Липкий» бит ведет начало от версий Unix для PDP-11, он использовался с обычными исполняемыми файлами[119]. Этот бит использовался с программами, которые предназначались для интенсивного использования, такими, как оболочка и редактор. Когда у программы был установлен этот бит, ядро хранило копию исполняемого кода программы на устройстве подкачки, из которого ее можно было быстро загрузить в память для повторного использования. (Загрузка из файловой системы занимает больше времени образ на устройстве подкачки хранился в смежных дисковых блоках, тогда как образ в файловой системе мог быть разбросан по всему диску). Исполняемые образы были «приклеены» к устройству подкачки, отсюда и название.
Таким образом, даже если программа в настоящее время не использовалась, предполагалось, что она вскоре могла быть использована другим пользователем, поэтому она могла быть быстро загружена.
В современных системах значительно более быстрые дисковое оборудование и память, чем в давнишней PDP-11. Они используют также методику, называемую подкачка по требованию, для загрузки в память лишь тех частей исполняемой программы, которые выполняются. Таким образом, сегодня «липкий» бит обычных исполняемых файлов не служит никаким целям и на самом деле ни на что не влияет.
Однако, в разделе 1.1.2 «Каталоги и имена файлов» мы упомянули, что «липкий» бит в каталоге, запись в который в других отношениях разрешена, предотвращает удаление файлов из этого каталога и их переименование любым пользователем, кроме владельца файла или
root$ ls -ld /tmp /* Показать права доступа к /tmp */drwxrwxrwt 19 root root 4096 Oct 20 14:04 /tmp$ cd /tmp /* Перейти туда */$ echo this is my file > arnolds-file /* Создать файл */$ ls -l arnolds-file /* Показать его права доступа */-rw-r--r-- 1 arnold devel 16 Oct 20 14:14 arnolds-file$ su - miriam /* Смена пользователя */Password:$ cd /tmp /* Перейти в /tmp */$ rm arnolds-file /* Попытка удаления файла */rm: remove write-protected regular file 'arnolds-file'? y /* rm предупреждает */rm: cannot remove 'arnolds-file': Operation not permitted /* Ядро запрещает удаление */Основным назначением этой особенности является как раз использование в таких каталогах, как
/tmpchmod +t$ mkdir mytmp /* Создать каталог */$ chmod a+wxt mytmp /* Добавить права записи для всех и «липкий» бит */$ ls -ld mytmp /* Проверить результат */drwxrwxrwt 2 arnold devel 4096 Oct 20 14:23 mytmpВ заключение, обратите внимание, что владелец каталога также может удалить файлы, даже если они не принадлежат ему.
11.6. Установка действительных и эффективных ID
Все становится интереснее, когда процессу приходится менять значения UID и GID. Установка набора групп проста. Изменение значений действительных и эффективных UID и GID сложнее.
11.6.1. Изменение набора групп
Функция
setgroups()#include /* Common */ #include #include int setgroups(size_t size, const gid_t *list);Параметр
sizelistВ отличие от функций для манипулирования значениями действительных и эффективных UID и GID, эту функцию может вызвать лишь процесс, действующий как
rootsetgroups()/bin/login/bin/sshdssh11.6.2. Изменение действительного и эффективного ID
Работа с двумя различными ID пользователей представляет для программиста приложения проблему. Могут быть вещи, которые программе нужно сделать, работая с эффективным UID, а другие вещи — работая с действительным UID.
Например, до того, как в системах Unix появилось управление заданиями, многие программы предоставляли переходы в оболочку, т.е. способ запуска команды или интерактивной оболочки из текущей программы. Хорошим примером этого является редактор
ed!!shТаким образом, имеется явная потребность в возможности замены эффективного UID действительным UID. Более того, полезна возможность обратного переключения эффективного UID на первоначальный. (В этом причина необходимости наличия сохраненного set-user ID; появляется возможность восстановления первоначальных привилегий, которые были у процесса при его запуске.)
Как и для множества Unix API, различные системы решили проблему разными способами, иногда с использованием одного и того же API, но с другой семантикой, а иногда введением другого API. Погружение в исторические подробности годится лишь для создания головной боли, поэтому мы не будем с этим беспокоиться. Вместо этого мы рассмотрим, что предоставляет POSIX и как работает каждый API. Более того, наше обсуждение фокусируется на значениях действительных и эффективных UID; значения GID работают аналогичным образом, поэтому мы не будем хлопотать с повторением подробностей для этих системных вызовов. Функции следующие:
#include /* POSIX */ #include int seteuid(uid_t euid); /* Установка эффективного ID */int setegid(gid_t egid);int setuid(uid_t uid); /* Установка эффективного ID, root устанавливает все */int setgid(gid_t gid);int setreuid(uid_t ruid, uid_t euid); /* Совместимость с BSD, устанавливаются оба */int setregid(gid_t rgid, gid_t egid);Есть три набора функций. Первые два были созданы POSIX:
int seteuid(uid_t euid)Эта функция устанавливает лишь эффективный UID. Обычный пользователь (не
rootПроцесс с эффективным UID, равным нулю, может установить в качестве эффективного UID любое значение. Поскольку в качестве значения эффективного UID можно установить также сохраненный set-user ID, процесс может восстановить свои привилегии root с помощью другого вызова
seteuid()int setegid(gid_t egid)Эта функция делает для эффективного ID группы то, что
seteuid()Следующий набор функций предлагает первоначальный API Unix для изменения действительных и эффективных UID и GID. В модели POSIX эти функции являются тем. что должна использовать программа с setuid-root для постоянного изменения действительного или эффективного UID:
int setuid(uid_t uid)Для обычного пользователя эта функция также устанавливает лишь эффективный UID. Как и для
seteuid()Однако, для
rootint setgid(gid_t gid)Эта функция делает для эффективного ID группы то же, что
setuid()rootЗАМЕЧАНИЕ. Возможность изменения ID группы зависит от эффективного ID пользователя. Эффективный GID, равный 0, не имеет особых привилегий.
Наконец, POSIX представляет для исторической совместимости две функции из BSD 4.2. В новом коде их лучше не использовать. Однако, поскольку вы, вероятно, увидите использующий эти функции старый код, мы их здесь опишем.
int setreuid(uid_t ruid, uid_t euid)Устанавливает данные значения в качестве действительного и эффективного UID. Значение -1 для
ruideuidchown()chown()fchown()lchown()rootrootint setregid(gid_t rgid, gid_t egid)Делает для действительных и эффективных ID групп то же, что
setreuid()rootСохраненный set-user ID в модели BSD не существует, поэтому лежащей в основе
setreuid()setregid()setreuid(geteuid(), getuid()); /* обмен действительным и эффективным */Однако, с принятием POSIX модели сохранения set-user ID и функций
seteuid()setegid()seteuid()setuid()setegid()setgid()11.6.3. Использование битов setuid и setgid
Есть важные случаи, в которых действующая как
rootloginРис. 11.1. От
initgettyloginКод для
login1.
initinitroot2.
init/etc/inittabinitgettyinitexec()gettymingettylogin:3. По получении регистрационного имени
gettyloginloginlogin4.
logindup()5. Затем
loginsetgroups()setgid()setuid()setuid()6. Наконец,
login/etc/profile$HOME/.profileОбратите внимание, как один процесс меняет свою сущность от системного процесса до процесса пользователя. Каждый потомок
initinitexec()setuid()rootexitinitgettylogin:ЗАМЕЧАНИЕ. Открытые файлы остаются открытыми и доступными для использования, даже после изменения процессом своих UID или GID. Таким образом, программы с setuid должны заранее открыть все нужные файлы, изменить их ID на ID действительного пользователя и продолжить оставшуюся часть работы без дополнительных привилегий
В табл. 11.1 приведена сводка шести стандартных функций для манипулирования значениями UID и GID.
Таблица 11.1. Сводка API для установки действительных и эффективных ID[120]
| Функция | Устанавливает | Постоянно | Обычный пользователь | Root |
|---|---|---|---|---|
|
E | Нет | Из R, E, S | Любое |
|
E | Нет | Из R, E, S | Любое |
|
Root: R,E,S Другие: E | Root: да Другие: нет | Из R, E | Любое |
|
Root: R,E,S Другие: E | Root: да Другие: нет | Из R, E | Любое |
|
E, может установить R | Нет | Из R, E | Любое |
|
E, может установить R | Нет | Из R, E | Любое |
11.7. Работа со всеми тремя ID: getresuid()
и setresuid()
(Linux)
getresuid()setresuid()Linux предоставляет дополнительные системные вызовы, посредством которых вы можете непосредственно работать с действительными, эффективными и сохраненными ID пользователя и группы:
#include /* Linux */ #include int getresuid(uid_t *ruid, uid_t *euid, uid_t *suid);int getresgid(gid_t *rgid, gid_t *egid, gid_t *sgid);int setresuid(uid_t ruid, uid_t euid, uid_t suid);int setresgid(gid_t rgid, gid_t egid, gid_t sgid);Функции следующие:
int getresuid(uid_t *ruid, uid_t *euid, uid_t *suid)Получает значения действительного, эффективного и сохраненного set-user ID. Возвращаемое значение 0 в случае успеха и -1 при ошибке,
errnoint getresgid(gid_t *rgid, gid_t *egid, gid_t *sgid)Получает значения действительного, эффективного и сохраненного set-group ID. Возвращаемое значение 0 в случае успеха и -1 при ошибке,
errnoint setresuid(uid_t ruid, uid_t euid, uid_t suid)Устанавливает значения действительного, эффективного и сохраненного set-user ID соответственно. Когда значение параметра равно -1, соответствующий UID остается без изменения.
Когда процесс действует как
rooteuidrootint setresgid(gid_t rgid, gid_t egid, gid_t sgid)Устанавливает значения действительного, эффективного и сохраненного set-group ID соответственно. Когда значение параметра равно -1, соответствующий GID остается без изменений.
Эта функция аналогична
setresuid()Функции
setresuid()setresgid()Более того, вызовы являются операциями типа «все или ничего»: они либо полностью успешны в осуществлении нужного изменения, либо терпят полную неудачу, оставляя текущее состояние как есть. Это повышает надежность, поскольку, опять-таки можно быть точно уверенным в том, что случилось.
11.8. Пересечение минного поля безопасности: setuid root
rootНастоящие минные поля трудно, но не невозможно перейти. Однако, это не является чем-то, что можно сделать легко, без тренировки или опыта
Точно также написание программ, которые используют setuid
rootВ частности, стоит специально изучить проблемы безопасности Linux/Unix и потратить время на обучение написанию программ setuid root. Если вы сразу нырнете в эту проблему, прочитав лишь эту книгу и ничего более, можно быть уверенным, что ваша система будет взломана, легко и сразу. Маловероятно, что вы или ваши клиенты будут довольны.
Вот несколько руководящих принципов:
• Как можно меньше действуйте в качестве
root• Соответствующим образом проектируйте свою программу. Разделите программу на составные части таким образом, чтобы все операции
root• При изменении или сбрасывании привилегий используйте
setresuid()setreuid(),setuid()• Переходите от
rootfork()exec()• Рассмотрите использование прав доступа setgid и особой группы для вашего приложения. Если это будет работать, это убережет вас от большой головной боли.
• Рассмотрите отказ от наследуемого окружения. Если вам нужно сохранить некоторые переменные окружения, сохраните как можно меньше. Убедитесь в предоставлении подходящих значений для переменных окружения
PATHIFS• Избегайте
execlp()execvp()PATHPATHЭто просто некоторые из множества тактик по пересечению опасной зоны, известной своими подвохами, минами-ловушками и фугасами. Ссылки на другие источники информации см. в следующем разделе.
11.9. Рекомендуемая литература
Безопасность Unix (а следовательно, и GNU/Linux) является темой, требующей знаний и опыта для того, чтобы справиться с ней должным образом. В Эпоху Интернета она стала лишь труднее, не проще.
1. Practical UNIX & Internet Security, 3rd edition, by Simson Garfinkel, Gene Spafford, and Alan Schwartz, O'Reilly & Associates, Sebastopol, CA, USA, 2003. ISBN: 0-596-00323-4.
Это стандартная книга по безопасности Unix.
2. Building Secure Software. How to Avoid Security Problems the Right Way, by John Viega and Gary McGraw. Addison-Wesley, Reading, Massachusetts, USA, 2001. ISBN: 0-201-72152-X.
Это хорошая книга по написанию безопасного программного обеспечения, она включает проблемы setuid. Предполагается, что вы знакомы с основными API Linux/Unix; к моменту прочтения данной книги вы должны быть готовы к ее прочтению.
3. "Setuid Demystified," by Hao Chen, David Wagner, and Drew Dean. Proceedings of the 11th USENIX Security Symposium, August 5–9, 2002 http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf.
Гарфинкель, Спаффорд и Шварц (Garfinkel, Spafford, Schwartz) рекомендуют прочтение этого материала «до того, как вы даже подумаете о написании кода, который пытается сохранять и восстанавливать привилегии». Мы всецело согласны с ними.
11.10. Резюме
• Использование значений ID пользователя и группы (UID и GID) для идентификации файлов и процессов — вот что превращает Linux и Unix в многопользовательские системы. Процессы имеют значения как действительных, так и эффективных UID и GID, а также набор дополнительных групп. Обычно именно эффективный UID определяет, как один процесс может повлиять на другой, и эффективные UID, GID и набор групп проверяются на соответствие с правами доступа к файлу. Пользователи с эффективным UID, равным нулю, известные как
root• Концепции сохраненных set-user ID и set-group ID пришли из System V и были приняты POSIX с полной поддержкой в GNU/Linux. Наличие этих отдельных значений ID дает возможность легко и безошибочно переключать при необходимости действительные и эффективные UID (и GID).
• Программы setuid и setgid создают процессы, в которых действительные и эффективные ID различаются. Программы как таковые помечаются дополнительными битами прав доступа к файлу. Биты setuid и setgid должны быть добавлены к файлу после его создания.
•
getuid()geteuid()getgid()getegid()getgroups()• Функция
access()stat()• Функция GLIBC
euidaccess()access()• «Липкий» бит и бит setgid при использовании с каталогами привносят дополнительную семантику. Когда для каталога установлен бит setgid, новые файлы в этом каталоге наследуют группу этого каталога. Новые каталоги делают то же самое, они также автоматически наследуют установку бита setgid. Без установленного бита setgid новые файлы и каталоги получают эффективный GID создающего их процесса. «Липкий» бит, установленный для каталогов, в которые в других отношениях разрешена запись, ограничивает право на удаление файла владельцем файла, владельцем каталога и
root• Набор групп изменяется с помощью
setgroups()root• Изменение UID и GID довольно сложно. Семантика различных системных вызовов с течением времени изменилась. Новые приложения, которые будут изменять лишь свои эффективные UID/GID, должны использовать
seteuid()setegid()rootsetuid()setgid()setreuid()setregid()• Приложения, действующие как
rootsetuid()setgid()loginroot• Функции Linux
setresuid()setresgid()• Написание приложений setuid-
rootУпражнения
1. Напишите простую версию команды
id$ iduid=2076(arnold) gid=42(devel) groups=19(floppy), 42(devel), 2076(arnold)Ее использование:
id [ пользователь ]id -G [ -nr ] [ пользователь ]id -g [ -nr ] [ пользователь ]id -u [ -nr ] [ пользователь ]При указанном пользователе выводятся сведения об этом пользователе; в противном случае
id -G -n -g -u 2. Напишите простую программу с именем
sumesume3. Как вы относитесь к тому, чтобы сделать
sume
Глава 12 Общие библиотечные интерфейсы — часть 2
В главе 6, «Общие библиотечные интерфейсы — часть 1», был представлен первый набор API библиотеки общего пользования. В некотором смысле, эти API поддерживают работу с фундаментальными объектами, которыми управляют системы Linux и Unix: время дня, пользователи и группы для файлов, сортировка и поиск.
Данная глава более эклектична; функции API, рассмотренные здесь, не особо связаны друг с другом. Однако, все они полезны в повседневном программировании под Linux/Unix. Наше представление движется от простых, более общих функций API к более сложным и более специализированным.
12.1. Операторы проверки: assert()
Оператор проверки (assertion) является утверждением, которое вы делаете о состоянии своей программы в определенный момент времени ее исполнения. Использование операторов проверок для программирования было первоначально разработано Хоаром (C.A.R. Hoare)[121]. Общая идея является частью «верификации программы»: так же, как вы проектируете и разрабатываете программу, вы можете показать, что она правильна, делая тщательно аргументированные утверждения о проявлениях кода вашей программы. Часто такие утверждения делаются об инвариантах — фактах о состоянии программы, которые, как предполагается, остаются верными на протяжении исполнения куска программы.
Операторы проверки особенно полезны для описания двух разновидностей инвариантов: предусловий и постусловий: условий, которые должны быть истинными соответственно перед и после исполнения сегмента кода. Простым примером предусловий и постусловий является линейный поиск:
/* lsearch --- возвратить индекс с данным значением в массиве или -1,
если не найдено */
int lsearch(int *array, size_t size, int value) {
size_t i;
/* предусловие: array != NULL */
/* предусловие: size > 0 */
for (i = 0; i < size; i++)
if (array[i] == value)
return i;
/* постусловие: i == size */
return -1;
}
Этот пример определяет условия, используя комментарии. Но не было бы лучше проверить условия с использованием кода? Это является задачей макроса
assert()
:
#include /* ISO С */
void assert(/* скалярное выражение */);
Когда скалярное выражение ложно, макрос
assert()
выводит диагностическое сообщение и завершает программу (с помощью функции abort()
; см. раздел 12.4 «Совершение самоубийства: abort()
»). ch12-assert.c
снова предоставляет функцию lsearch()
, на этот раз с оператором проверки и функцией main()
:
1 /* ch12-assert.с --- демонстрация операторов проверки */
2
3 #include
4 #include
5
6 /* lsearch --- возвращает индекс с данным значением в массиве или -1, если не найдено */
7
8 int lsearch(int *array, size_t size, int value)
9 {
10 size_t i;
11
12 assert(array != NULL);
13 assert(size > 0);
14 for (i = 0; i < size; i++)
15 if (array[i] == value)
16 return i;
17
18 assert(i == size);
19
20 return -1;
21 }
22
23 /* main --- проверить наши условия */
24
25 int main(void)
26 {
27 #define NELEMS 4
28 static int array[NELEMS] = { 1, 17, 42, 91 };
29 int index;
30
31 index = lsearch(array, NELEMS, 21);
32 assert(index == -1);
33
34 index = lsearch(array, NELEMS, 17);
35 assert(index == 1);
36
37 index = lsearch(NULL, NELEMS, 10); /* won't return */
38
39 printf("index = %d\n", index);
40
41 return 0;
42 }
После компиляции и запуска оператор проверки в строке 12 «выстреливает»:
$ ch12-assert /* Запуск программы */
ch12-assert: ch12-assert.c:12: lsearch: Assertion 'array != ((void *)0)' failed.
Aborted (core dumped)
Сообщение от
assert()
варьирует от системы к системе. Для GLIBC на GNU/Linux сообщение включает имя программы, имя файла с исходным кодом и номер строки, имя функции, а затем текст завершившегося неудачей условия. (В этом случае именованная константа NULL
проявляется в виде своего макрорасширения '((void*)0)'
.)
Сообщение '
Aborted (core dumped)
' означает, что ch12-assert
создала файл core
; т.е. снимок адресного пространства процесса непосредственно перед его завершением.[122] Этот файл может быть использован впоследствии с отладчиком; см. раздел 15.3 «Основы GDB». Создание файла core
является намеренным побочным результатом assert()
; предполагается, что произошла решительная ошибка, и вы хотите исследовать процесс с помощью отладчика для ее определения.
Вы можете отменить оператор проверки, компилируя свою программу с помощью опции командной строки '
-DNDEBUG
'. Когда этот макрос определен до включения
, макрос assert()
расширяется в код, который ничего не делает. Например:
$ gcc -DNDEBUG=1 ch12-assert.c -о ch12-assert /* Компиляция с -DNDEBUG */
$ ch12-assert /* Запуск */
Segmentation fault (core dumped) /* Что случилось? */
Здесь мы получили настоящий дамп ядра! Мы знаем, что операторы проверки были запрещены; сообщения «failed assertion» нет. Что же случилось? Рассмотрите строку 15
lsearch()
при вызове из строки 37 main()
. В этом случае переменная array
равна NULL
. Доступ к памяти через указатель NULL
является ошибкой. (Технически различные стандарты оставляют «неопределенным» то, что происходит при разыменовывании указателя NULL
. Наиболее современные системы делают то же, что и GNU/Linux; они завершают процесс, посылая ему сигнал SIGSEGV
; это, в свою очередь, создает дамп ядра. Этот процесс описан в главе 10 «Сигналы».
Этот случай поднимает важный момент относительно операторов проверки. Часто программисты ошибочно используют операторы проверки вместо проверки ошибок времени исполнения. В нашем случае тест '
array != NULL
' должен был быть проверкой времени исполнения:
if (array == NULL) return -1;
Тест '
size > 0
' (строка 13) менее проблематичен; если size
равен 0 или меньше 0, цикл никогда не исполнится, и lsearch()
(правильно) возвратит -1. (По правде, этот оператор проверки не нужен, поскольку код правильно обрабатывает случай 'size <= 0
'.)
Логика, стоящая за отменой оператора проверки, заключается в том, что дополнительные проверки могут снизить производительность программы и поэтому должны быть запрещены в заключительной версии программы. Хоар[123], однако, сделал такое замечание:
«В конце концов, абсурдно делать тщательные проверки безопасности при отладочных запусках, когда к результатам нет никакого доверия, а затем удалять их из финальных версий, когда ошибочный результат может быть дорогим или катастрофическим. Что бы мы подумали об энтузиасте-мореплавателе, который надевает свой спасательный жилет при тренировке на сухой земле и снимает его, как только выходит в море?»
С такими мнениями, наша рекомендация заключается во внимательном использовании операторов проверки- во-первых, для любого данного оператора проверки рассмотрите возможность использования вместо него проверки времени исполнения. Во-вторых, тщательно разместите свой оператор проверки, чтобы не было возражений против их оставления на своем месте лаже в финальной версии вашей программы.
Наконец, отметим следующее из раздела «Ошибки» справочной страницы GNU/Linux assert(3):
assert()
реализован как макрос: если у проверяемого выражения есть побочные результаты, поведение программы может меняться в зависимости от того, определен ли NDEBUG
. Это может создавать гейзенберговские ошибки, которые исчезают при отключении режима отладки.
Знаменитый принцип неопределенности Гейзенберга из физики указывает, что чем более точно вы определите скорость частицы, тем менее точно вы определите ее положение, и наоборот. В терминах непрофессионала это означает что простой факт наблюдения частицы влияет на нее.
Сходное явление совершается в программировании, не связанном с физикой частиц: действие компилирования программы для отладки или запуска ее а режиме отладки может изменить поведение программы. В частности, первоначальная ошибка может исчезнуть. Такие ошибки в разговоре называют гейзенберговскими.
Справочная страница предостерегает нас от использования при вызовах
assert()
выражений с побочными эффектами:
assert(*p++ == '\n');
Здесь побочным эффектом является увеличение указателя p как часть теста. Когда определен
NDEBUG
, аргумент выражения исчезает из исходного кода; он никогда не исполняется. Это может привести к неожиданной неудаче. Однако, как только при подготовке к отладке запрет на операторы проверки отменяется, все начинает снова работать! Такие проблемы трудно отследить.
12.2. Низкоуровневая память: функции memXXX()
Несколько функций предоставляют возможность для работы с произвольными блоками памяти низкоуровневые службы. Все их имена начинаются с префикса '
mem
':
#include /* ISO C */
void *memset(void *buf, int val, size_t count);
void *memcpy(void *dest, const void *src, size_t count);
void *memmove(void *dest, const void *src, size_t count);
void *memccpy(void *dest, const void *src, int val, size_t count);
int memcmp(const void *buf1, const void *buf2, size_t count);
void *memchr(const void *buf, int val, size_t count);
12.2.1. Заполнение памяти: memset()
Функция
memset()
копирует значение val (интерпретируемое как unsigned char
) в первые count
байтов буфера buf
. Она особенно полезна для обнуления блоков динамической памяти:
void *p = malloc(count);
if (p != NULL)
memset(p, 0, count);
Однако
memset()
может использоваться с любой разновидностью памяти, не только с динамической. Возвращаемым значением является первый аргумент: buf
.
12.2.2. Копирование памяти: memcpy()
, memmove()
и memccpy()
Три функции копируют один блок памяти в другой. Первые две функции отличаются в обработке перекрывающихся областей памяти; третья копирует память, но останавливается при встрече с определенным значением.
void *memcpy(void *dest, const void *src, size_t count)
Это простейшая функция. Она копирует
count
байтов из src
в dest
. Она не обрабатывает перекрывающиеся области памяти. Функция возвращает dest
.
void *memmove(void *dest, const void *src, size_t count)
Подобно
memcpy()
, она также копирует count
байтов из src
в dest
. Однако, она обрабатывает перекрывающиеся области памяти. Функция возвращает dest
.
void *memccpy(void *dest, const void *src, int val, size_t count)
Эта копирует байты из
src
в dest
, останавливаясь либо после копирования val
в dest
, либо после копирования count
байтов. Если она находит val
, то возвращает указатель на положение в dest
сразу за val
. В противном случае возвращается NULL
.
Теперь, в чем проблема с перекрывающейся памятью? Рассмотрим рис. 12.1.
Рис. 12.1. Перекрывающиеся копии
Целью является скопировать четыре экземпляра
struct xyz
от data[0]
до data[3]
в участок от data[3]
до data[6]
. Здесь проблемой является data[3]
, побайтовое копирование с перемещением в памяти из data[0]
затрет data[3]
до того, как он будет безопасно скопирован в data[6]
! (Может возникнуть также сценарий, когда копирование в памяти в обратном направлении разрушит перекрывающиеся данные.)
Функция
memcpy()
была первоначальной функцией в System V API для копирования блоков памяти; ее поведение для перекрывающихся блоков памяти не была подробно определена тем или иным способом. Для стандарта С 1989 г. комитет почувствовал, что это отсутствие определенности является проблемой, поэтому они придумали memmove()
. Для обратной совместимости memcpy()
была оставлена, причем поведение для перекрывающейся памяти было специально отмечено как неопределенное, а в качестве процедуры, корректно разрешающей проблемные случаи, была предложена memmove()
.
Какую из них использовать в своем коде? Для библиотечной функции, которая не знает, какие области памяти ей передаются, следует использовать
memmove()
. Таким способом вы гарантируете, что не будет проблем с перекрывающимися областями. Для кода приложения, который «знает», что две области не перекрываются, можно безопасно использовать memcpy()
.
Как для
memcpy()
, так и для memmove()
(как и для strcpy()
) буфер назначения является первым аргументом, а источник — вторым. Чтобы запомнить это, обратите внимание на порядок, который тот же самый, как в операторе присваивания:
dest = src;
(Справочные страницы во многих системах не помогают, предлагая прототип в виде '
void *memcpy(void *buf1, void *buf2, size_t n)
' и полагаясь на то, что текст объяснит, что есть что. К счастью, справочная страница GNU/Linux использует более осмысленные имена.)
12.2.3. Сравнение блоков памяти: memcmp()
Функция
memcmp()
сравнивает count
байтов из двух произвольных буферов данных. Возвращаемое ею значение подобно strcmp()
: отрицательное, нулевое или положительное, если первый буфер меньше, равен или больше второго.
Вы можете поинтересоваться: «Почему бы не использовать для такого сравнения
strcmp()
?» Разница между двумя функциями в том, что memcmp()
не принимает во внимание нулевые байты (завершающий строку '\0
'.) Таким образом, memcmp()
является функцией, которая используется, когда вам нужно сравнить произвольные двоичные данные.
Другим преимуществом
memcmp()
является то, что она быстрее типичной реализации на C:
/* memcmp --- пример реализации на С, НЕ для реального использования */
int memcmp(const void *buf1, const void *buf2, size_t count) {
const unsigned char *cp1 = (const unsigned char*)buf1;
const unsigned char *cp2 = (const unsigned char*)buf2;
int diff;
while (count-- != 0) {
diff = *cp1++ - *cp2++;
if (diff != 0)
return diff;
}
return 0;
}
Скорость может быть достигнута в результате использования специальных инструкций «блочного сравнения памяти», которые поддерживают многие архитектуры, или в результате сравнения единиц, превышающих байты. (Эта последняя операция коварна, и лучше оставить ее автору библиотеки.)
По этим причинам всегда следует использовать вашу библиотечную версию
memcmp()
вместо прокручивания своей собственной. Велика вероятность, что автор библиотеки знает машину лучше вас
12.2.4. Поиск байта с данным значением: memchr()
Функция
memchr()
сходна с функцией strchr()
: она возвращает местоположение определенного значения внутри произвольного буфера. Как и в случае memcmp()
против strcmp()
, основной причиной для использования memchr()
является использование произвольных двоичных данных.
GNU
wc
использует memchr()
при подсчете лишь строк и байтов[124], и это позволяет wс
быть быстрой. Из wc.c
в GNU Coreutils:
257 else if (!count_chars && !count_complicated)
258 {
259 /* Использует отдельный цикл при подсчете лишь строк или строк и байтов -
260 но не символов или слов. */
261 while ((bytes_read = safe_read(fd, buf, BUFFER_SIZE)) > 0)
262 {
263 register char *p = buf;
264
265 if (bytes_read == SAFE_READ_ERROR)
266 {
267 error(0, errno, "%s", file);
268 exit_status = 1;
269 break;
270 }
271
272 while ((p = memchr(p, '\n', (buf + bytes_read) - p)))
273 {
274 ++p;
275 ++lines;
276 }
277 bytes += bytes_read;
278 }
279 }
Внешний цикл (строки 261–278) читает блоки данных из входного файла. Внутренний цикл (строки 272–276) использует
memchr()
для поиска и подсчета символов конца строки. Сложное выражение '(buf + bytes_read) - р
' сводится к числу оставшихся байтов между текущим значением p и концом буфера.
Комментарии в строках 259–260 нуждаются в некотором объяснении. Вкратце, современные системы могут использовать символы, занимающие более одного байта в памяти и на диске. (Это несколько более подробно обсуждается в разделе 13.4 «Не могли бы вы произнести это для меня по буквам?».) Таким образом,
wc
должна использовать другой код, если она различает байты и символы: этот код имеет дело со случаем подсчета байтов.
12.3. Временные файлы
Временный файл является в точности тем, что звучит в его названии: файл, в котором при исполнении программы хранятся данные, которые больше не нужны после завершения программы.
sort
читает со стандартного ввода, если в командной строке не указаны файлы или вы используете в качестве имени файла '-
'. Тем не менее, sort
должна прочесть все
свои входные данные, прежде чем сможет вывести отсортированные результаты. (Подумайте об этом немного, и вы увидите, что это так.) Когда читается стандартный ввод, данные должны быть где-то сохранены, прежде чем sort
сможет их отсортировать; это отличное применение для временного файла. sort
использует временные файлы также для хранения промежуточных результатов сортировки.
Удивительно, но имеются пять различных функций для создания временных файлов. Три из них работают посредством создания строк, представляющих (предположительно) уникальные имена файлов. Как мы увидим, их обычней следует избегать. Оставшиеся две работают путем создания и открытия временного файла; эти функции предпочтительнее для использования.
12.3.1. Создание временных имен файлов (плохо)
Имеются три функции, назначением которых является создание имени уникального, не существующего файла. Получив такое имя, вы можете использовать его для создания временного файла. Поскольку имя уникально, вам «гарантируется» исключительное использование файла. Вот объявления функций:
#include
char *tmpnam(char *s); /* ISO С */
char *tempnam(const char *dir, const char *pfx); /* XSI */
char *mktemp(char *template); /* ISO С */
Все эти функции предусматривают различные вариации одной и той же темы они заполняют или создают буфер с путем уникального временного имени файла. Файл уникален в том, что создаваемое имя не существует во время создания и возвращения его функциями. Функции работают следующим образом:
char *tmpnam(char *s)
Генерирует уникальное имя файла. Если
s
не равен NULL
, он должен быть размером по крайней мере L_tmpnam
байтов, и в него копируется уникальное имя. Если s
равен NULL
, имя генерируется во внутреннем статическом буфере, который может быть переписан при последующих вызовах. Префикс каталогов в пути будет P_tmpdir
. Как P_tmpdir
, так и L_tmpnam
определены в
.
char *tempnam(const char *dir, const char *pfx)
Подобно
tmpnam()
дает вам возможность указать префикс каталогов. Если dir
равен NULL
, используется P_tmpdir
. Аргумент pfx
, если он не равен NULL
, определяет до пяти символов для использования в качестве начальных символов имени файла tempnam()
выделяет память для имен файлов, которые она генерирует. Возвращенный указатель может впоследствии использоваться с free()
(и это следует сделать, если хотите избежать утечек памяти).
char *mktemp(char *template)
Генерирует уникальные имена файлов на основе шаблона. Последними шестью символами
template
должны быть 'ХХХХХХ
'; эти символы замещаются уникальным суффиксом.
ЗАМЕЧАНИЕ. Аргумент
template
функции mktemp()
переписывается. Поэтому он не должен быть строковой константой. Многие компиляторы, предшествовавшие стандарту С, помещают строковые константы в сегмент данных вместе с обычными глобальными переменными. Хотя в исходном коде они определены как константы, их можно переписать, таким образом, нередко встречался такой код:
/* Код в старом стиле: не используйте его */
char *tfile = mktemp("/tmp/myprogXXXXXX");
/* ...использование файла... */
На современных системах такой код. вероятно, завершится неудачей, в наши дни строковые константы находятся в сегментах памяти только для чтения.
Использование этих функций довольно просто. Файл
ch12-mktemp.c
демонстрирует mktemp()
; нетрудно изменить его для использования других функций:
1 /* ch12-mktemp.с --- демонстрирует простое использование mktemp().
2 Для краткости проверка ошибок опущена */
3
4 #include
5 #include /* для флагов открытия */
6 #include /* для PATH_MAX */
7
8 int main(void)
9 {
10 static char template[] = "/tmp/myfileXXXXXX";
11 char fname[PATH_MAX];
12 static char mesg[] =
13 "Here's lookin' at you, kid'\n"; /* вместо "hello, world" */
14 int fd;
15
16 strcpy(fname, template);
17 mktemp(fname);
18
19 /* ОКНО СОСТОЯНИЯ ГОНКИ ОТКРЫВАЕТСЯ */
20
21 printf("Filename is %s\n", fname);
22
23 /* ОКНО СОСТОЯНИЯ ГОНКИ ТЯНЕТСЯ ДОСЮДА */
24
25 fd = open(fname, O_CREAT|O_RDWR|O_TRUNC, 0600);
26 write(fd, mesg, strlen(mesg));
27 close(fd);
28
29 /* unlink(fname); */
30
31 return 0;
32 }
Переменная
template
(строка 10) определяет шаблон имени файла; 'ХХХХХХ
' будет заменен уникальным значением. Строка 16 копирует шаблон в fname
, которая не является константой: ее можно изменить. Строка 18 вызывает mktemp()
для генерирования имени файла, а строка 21 выводит ее, так, чтобы мы могли видеть, что это такое. (Вскоре мы объясним комментарии в строках 19 и 23.)
Строка 25 открывает файл, создавая его при необходимости. Строка 26 записывает сообщение в
mesg
, а строка 27 закрывает файл. В программе, в которой файл должен быть удален после завершения работы с ним, строка 29 была бы не закомментирована. (Иногда временный файл не следует удалять; например, если файл после полной записи будет переименован.) Мы закомментировали ее, чтобы можно было запустить эту программу и посмотреть на файл впоследствии. Вот что происходит при запуске программы:
$ ch12-mktemp /* Запуск программы */
Filename is /tmp/myfileQES4WA /* Вывод имени файла */
$ cat /tmp/myfileQES4WA
Here's lookin' at you, kid' /* Содержит то, что ожидалось */
$ ls -l /tmp/myfileQES4WA /* To же с владельцем и доступом */
-rw------- 1 arnold devel 28 Sep 18 09:27 /tmp/myfileQES4WA
$ rm /tmp/myfileQES4WA /* Удалить его */
$ ch12-mktemp / * Используется ли повторно то же имя? */
Filename is /tmp/myfileic7xCy /* Нет. Это хорошо */
$ cat /tmp/myfileic7xCy /* Снова проверить содержание */
Here's lookin' at you, kid!
$ ls -l /tmp/myfileic7xCy /* Снова проверить владельца и доступ */
-rw------- 1 arnold devel 28 Sep 18 09:28 /tmp/myfileic7xCy
Все кажется работающим замечательно,
mktemp()
возвращает уникальное имя, ch12-mktemp
создает файл с нужными правами доступа, и содержание то самое, которое ожидалось. Так в чем же проблема со всеми этими функциями?
Исторически
mktemp()
использовала простой, предсказуемый алгоритм для создания замещающих символов для 'ХХХХХХ
' в шаблоне. Более того, интервал между временем, когда генерируется имя файла, и временем, когда создается сам файл, создает состояние гонки.
Как? Ну, Linux и Unix являются системами с квантованием времени, методикой, которая разделяет время процессора между всеми исполняющимися процессами. Это означает, что, хотя программа кажется выполняющейся все время, в действительности есть моменты, когда процессы спят, т.е. ожидают выполнения на процессоре.
Теперь рассмотрите программу профессора для отслеживания оценок студентов. Как профессор, так и злоумышленный студент в одно и то же время используют сильно нагруженную многопользовательскую систему. Программа профессора использует для создания временных файлов
mktemp()
, видевший в прошлом, как оценивающая программа создает и удаляет временные файлы, выяснил алгоритм, который использует mktemp()
. (В версии GLIBC нет этой проблемы, но не все системы используют GLIBC!) Рис 12.2 иллюстрирует состояние гонки и то, как студент его использует.
Рис. 12.2. Состояние гонки с
mktemp()
Вот что случилось.
1. Оценивающая программа использует
mktemp()
для создания имени файла. По возвращении из mktemp()
открыто окно состояния гонки (строка 19 в ch12-.mktemp.c
).
2. Ядро останавливает оценивающую программу, чтобы могли поработать другие программы в системе. Это происходит до вызова
open()
.
Пока оценивающая программа остановлена, студент создает файл с тем же самым именем, которое вернула
mktemp()
. (Помните, выяснить алгоритм было просто.) Студент создает файл с дополнительной ссылкой, так что когда оценивающая программа удаляет файл, он все еще будет доступен для прочтения.
3. Теперь оценивающая программа открывает файл и записывает в него данные. Студент создал файл с правами доступа
-rw-rw-rw-
, поэтому это не представляет проблему.
4. Когда оценивающая программа завершает работу, она удаляет временный файл. Однако, у студента все еще есть копия. Например, может быть возможность получения прибыли при заблаговременной продаже своим товарищам их оценок.
Наш пример упрощенный; помимо простого похищения данных с оценками умный (хотя и аморальный) студент мог бы вместо этого изменить данные. Если бы профессор не проверял результаты работы своей программы дважды, никто бы ничего не узнал.
ЗАМЕЧАНИЕ. Мы не рекомендуем делать что-либо из этого! Если вы студент, не пытайтесь сделать что-либо подобное. Первое и самое главное, это неэтично. Во-вторых, вас могут выгнать из школы. В-третьих, ваши профессора, наверное, не сталь наивны, чтобы использовать
mktemp()
в своих программах. Этот пример лишь для иллюстрации!
По приведенным и другим причинам, все три описанные в данном разделе функции не следует никогда использовать. Они существуют в POSIX и GLIBC лишь для поддержки старых программ, которые были написаны до того, как была осознана опасность этих процедур С этой целью системы GNU/Linux генерируют во время компоновки сообщение:
$ cc ch12-mktemp.c -о ch12-mktemp /* Компилировать программу */
/tmp/cc1XCvD9.о(.text+0x35): In function 'main':
: the use of 'mktemp' is dangerous, better use 'mkstemp'
(Мы рассмотрим
mkstemp()
в следующем подразделе.)
Если бы в вашей системе не было
mkstemp()
, подумайте, как вы могли бы использовать эти интерфейсы для ее эмулирования. (См. также «Упражнения» для главы 12 в конце.)
12.3.2. Создание и открывание временных файлов (хорошо)
Есть две функции, не имеющие проблем состояния гонки. Одна из них предназначена для использования с библиотекой
:
#include /* ISO С */
FILE *tmpfile(void);
Другая функция для использования с системными вызовами на основе дескрипторов файлов:
#include /* XSI */
int mkstemp(char* template);
tmpfile()
возвращает значение FILE*
, представляющее уникальный открытый временный файл. Файл открывается в режиме "w+b
". w+
означает «открыть для чтения и записи, сначала урезав файл», a b означает двоичный, а не текстовый режим. (На системах GNU/Linux или Unix нет разницы, но на других системах есть.) Файл автоматически удаляется, когда закрывается указатель файла; нет способа получить имя файла, чтобы сохранить его содержимое. Программа в ch12-tmpfile.c
демонстрирует tmpfile()
:
/* ch12-tmpfile.с --- демонстрация tmpfile().
Проверка ошибок для краткости опущена */
#include
int main(void) {
static char mesg[] =
"Here's lookin' at you, kid!"; /* заменяет "hello, world" */
FILE *fp;
char buf[BUFSIZ];
fp = tmpfile(); /* Получить временный файл */
fprintf(fp, "%s", mesg); /* Записать s него */
fflush(fp); /* Сбросить на диск */
rewind(fp); /* Перейти в начало */
fgets(buf, sizeof buf, fp); /* Прочесть содержимое */
printf("Got back <%s>\n", buf); /* Вывести полученные данные */
fclose(fp); /* Закрыть файл, закончить */
return 0; /* Все сделано */
}
Возвращенное значение
FILE*
не отличается от любого другого FILE*
, возвращенного fopen()
. При запуске получаем ожидавшиеся результаты:
$ ch12-tmpfile
Got back
Ранее мы видели, что авторы GLIBC рекомендуют использование функции
mkstemp()
:
$ cc ch12-mktemp.с -о ch12-mktemp /* Компилировать программу */
/tmp/cc1XCvD9.о(.text+0x35): In function "main':
: the use of 'mktemp' is dangerous, better use 'mkstemp'
Эта функция похожа на
mktemp()
в том, что она принимает имя файла, оканчивающееся на 'ХХХХХХ
', и заменяет эти символы уникальным суффиксом для создания уникального имени файла. Однако, она идет на один шаг дальше. Она создает и открывает файл. Файл создается с доступом 0600 (т.е. -rw-------
). Таким образом, доступ к файлу может получить только пользователь, запустивший программу.
Более того, и это то, что делает
mkstemp()
более безопасной, файл создается с флагом O_EXCL
, который гарантирует, что файл не существует, и не дает никому больше открыть файл.
Возвращаемое значение является дескриптором открытого файла, который может использоваться для чтения и записи. Для удаления файла после завершения работы с ним должно использоваться имя пути, сохраненное теперь в переданном
mkstemp()
буферу. Все это демонстрируется в ch12-mkstemp.c
, который является простой модификацией ch12-tmpfile.с
:
/* ch12-mkstemp.с --- демонстрирует mkstemp().
Проверка ошибок для краткости опущена */
#include
#include /* для флагов открытия */
#include /* для PATH_МАХ */
int main(void) {
static char template[] = "/tmp/myfileXXXXXX";
char fname[PATH_MAX];
static char mesg[] =
"Here's lookin' at you, kid!\n"; /* заменяет "hello, world" */
int fd;
char buf[BUFSIZ];
int n;
strcpy(fname, template); /* Копировать шаблон */
fd = mkstemp(fname); /* Создать и открыть временный файл */
printf("Filename is %s\n", fname); /* Вывести его для сведений */
write(fd, mesg, strlen(mesg)); /* Что-нибудь записать в файл */
lseek(fd, 0L, SEEK_SET); /* Перейти в начало */
n = read(fd, buf, sizeof(buf));
/* Снова прочесть данные; НЕ завышается '\0'! */
printf("Got back: %.*s", n, buf); /* Вывести его для проверки */
close(fd); /* Закрыть файл */
unlink(fname); /* Удалить его */
return 0;
}
При запуске получаем ожидавшиеся результаты:
$ ch12-mkstemp
Filename is /tmp/myfileuXFWIN
Got back: Here's lookin' at you, kid!
12.3.3. Использование переменной окружения TMPDIR
Многие стандартные утилиты обращают внимание на переменную окружения
TMPDIR
, используя обозначенный в ней каталог в качестве места для помещения временных файлов. Если TMPDIR
не установлена, каталогом по умолчанию для временных файлов обычно является /tmp
, хотя на многих современных системах есть также и каталог /var/tmp
. /tmp
обычно очищается от всех файлов и каталогов административными сценариями оболочки при запуске.
Многие системы GNU/Linux предоставляют каталог
/dev/shm
, использующий файловую систему типа tmpfs:
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda2 6198436 5136020 747544 88% /
/dev/hda5 61431520 27720248 30590648 48% /d
none 256616 0 256616 0% /dev/shm
Тип файловой системы
tmpfs
предоставляет электронный (RAM) диск: часть памяти, которая используется, как если бы она была диском. Более того, файловая система tmpfs
использует механизмы виртуальной памяти ядра Linux для его увеличения сверх фиксированного размера. Если на вашей системе уйма оперативной памяти, этот подход может обеспечить заметное ускорение. Чтобы протестировать производительность, мы начали с файла /usr/share/dict/linux.words
, который является отсортированным списком правильно написанных слов, по одному в строке. Затем мы перемешали этот файл, так что он больше не был сортированным, и создали больший файл, содержащий 500 копий спутанной версии файла:
$ ls -l /tmp/randwords.big /* Показать размер */
-rw-r--r-- 1 arnold devel 204652500 Sep 18 16:02 /tmp/randwords.big
$ wc -l /tmp/randwords.big /* Сколько слов? */
22713500 /tmp/randwords.big /* Свыше 22 миллионов! */
Затем мы отсортировали файл, используя сначала каталог
/tmp
, а затем с TMPDIR
, установленным в /dev/shm
[125]:
$ time sort /tmp/randwords.big > /dev/null
/* Использование реальных файлов */
real 1m32.566s
user 1m23.137s
sys 0m1.740s
$ time TMPDIR=/dev/shm sort /tmp/randwords.big > /dev/null
/* Использование электронного диска */
real 1m28.257s
user 1m18.469s
sys 0m1.602s
Интересно, использование электронного диска было лишь незначительно быстрее, чем использование обычных файлов. (В некоторых дальнейших тестах оно было даже в действительности медленнее!) Мы предполагаем, что в игру вступил буферный кэш ядра (см. раздел 4.6.2 «Создание файлов с помощью
creat()
»), весьма эффективно ускоряя файловый ввод/вывод[126].
У электронного диска есть важный недостаток: он ограничен сконфигурированным для вашей системы размером пространства для подкачки.[127] Когда мы попытались отсортировать файл, содержащий 1000 копий файла с перемешанными словами, место на электронном диске закончилось, тогда как обычный sort завершился благополучно.
Использовать TMPDIR для своих программ просто. Мы предлагаем следующую схему.
const char template[] = "myprog.XXXXXX";
char *tmpdir, *tfile;
size_t count;
int fd;
if ((tmpdir = getenv("TMPDIR")) == NULL)
/* Использовать значение TMPDIR, если имеется */
tmpdir = "/tmp"; /* В противном случае, /tmp по умолчанию */
count = strlen(tmpdir) + strlen(template) + 2;
/* Вычислить размер имени файла */
tfile = (char *)malloc(count); /* Выделить для него память */
if (tfile == NULL) /* Проверка ошибок */
/* восстановить */
sprintf(tfile, "%s/%s", tmpdir, template);
/* Создать завершающий шаблон */
fd = mkstemp(tfile); /* Создать и открыть файл */
/* ...использование tempfile через fd... */
close(fd); /* Очистка */
unlink(tfile);
free(tfile);
В зависимости от потребностей вашего приложения, вы можете захотеть немедленно удалить файл после его открытия, вместо его удаления как части завершающей очистки.
12.4. Совершение самоубийства: abort()
Бывают моменты, когда программа просто не может продолжаться. Обычно лучше всего при этом выдать сообщение об ошибке и вызвать
exit()
. Однако, особенно для ошибок, являющихся проблемами программирования, полезно не только завершиться, но и создать дамп ядра, который сохраняет в файле состояние работающей программы для последующего исследования в отладчике. В этом заключается работа функции abort()
:
#include /* ISO С */
void abort(void);
Функция
abort()
посылает сигнал SIGABRT
самому процессу. Это случится, даже если SIGABRT
заблокирован или игнорируется. После этого осуществляется обычное для SIGABRT
действие, которое заключается в создании дампа ядра.
Примером
abort()
в действии является макрос assert()
, описанный в начале данной главы. Когда assert()
обнаруживает, что его выражение ложно, он выводит сообщение об ошибке, а затем вызывает abort()
для создания дампа ядра.
В соответствии со стандартом С, осуществляет
abort()
очистку или нет, зависит от реализации. Под GNU/Linux она выполняет очистку: все потоки FILE*
перед завершением программы закрываются. Обратите, однако, внимание, что для открытых файлов, использующих системные вызовы на основе дескрипторов файлов, ничего не делается. (Если открыты лишь файлы или каналы, ничего не нужно делать. Хотя мы не обсуждали это, дескрипторы файлов используются также для сетевых соединений, и оставление их открытыми является плохой практикой.)
12.5. Нелокальные переходы
«Идите прямо в тюрьму. Не проходите GO. Не забирайте 200$».
Вы, без сомнения, знаете, чем является
goto
: передачей потока управления на метку где-то в текущей функции. Операторы goto
при скупом употреблении могут послужить удобочитаемости и правильности функции (Например, когда все проверки ошибок используют goto
для перехода на метку в конце функции, такую, как clean_up
, код с этой меткой проводит очистку [закрывая файлы и т.п.] и возвращается.) При плохом использовании операторы goto
могут привести к так называемой «лапше» в коде, логику которого становится невозможно отследить.
Оператор
goto
в языке С ограничен переходом на метку в текущей функции. Многие языки в семействе Алгола, такие, как Паскаль, допускают использование goto
для выхода из вложенной функции в предшествующую вызывающую функцию. Однако в С нет способа, в пределах синтаксиса самого языка, перейти в определенную точку другой функции, пусть даже и вызывающей. Такой переход называется нелокальным переходом.
Почему полезен нелокальный переход? Рассмотрите интерактивную программу, которая считывает и выполняет программы. Предположим, пользователь запускает длительное задание, разочаровывается или меняет мнение о данном задании и нажимает CTRL-С для генерирования сигнала
SIGINT
. Когда запускается обработчик сигнала, он может перейти обратно в начало главного цикла чтения и обработки команд. Строковый редактор ed представляет простой пример этого:
$ ed -p '> ' sayings /* Запуск ed, '> ' используется как приглашение */
sayings: No such file or directory
> a /* Добавить текст */
Hello, world
Don't panic
^C /* Сгенерировать SIGINT */
? /* Сообщение об ошибке ''один размер подходит всем'' */
> 1,$p /* ed возвращается в командную строку */
Hello, world /* '1,$p' prints all the lines */
Don't panic
> w /* Сохранить файл */
25
> q /* Все сделано */
Внутри себя
ed
устанавливает перед циклом команд точку возврата, и обработчик сигнала осуществляет нелокальный переход на эту точку возврата.
12.5.1. Использование стандартных функций: setjmp()
и longjmp()
Нелокальные переходы осуществляются с помощью функций
setjmp()
и longjmp()
. Эти функции используются в двух разновидностях. Традиционные процедуры определены стандартом ISO С:
#include /* ISO С */
int setjmp(jmp_buf env);
void longjmp(jmp_buf env, int val);
Тип
jmp_buf
определен через typedef
в
. setjmp()
сохраняет текущее «окружение» в env
. env
обычно является глобальной или статической на уровне файла переменной, так что она может использоваться из вызванной функции. Это окружение включает любую информацию, необходимую для перехода на местоположение, из которого была вызвана setjmp()
. Содержание jmp_buf
по своей природе машинно-зависимо; таким образом, jmp_buf
является непрозрачным типом: тем, что вы используете, не зная, что находится внутри него.
setjmp()
возвращает 0, когда она вызывается для сохранения в jmp_buf
текущего окружения. Ненулевое значение возвращается, когда с использованием окружения осуществляется нелокальный переход:
jmp_buf command_loop; /* На глобальном уровне */
/* ... затем в main() ... */
if (setjmp(command_loop) == 0) /* Состояние сохранено, продолжить */
;
else /* Мы попадаем сюда через нелокальный переход */
printf("?\n"); /* ed's famous message */
/* ... теперь начать цикл команд ... */
longjmp()
осуществляет переход. Первым параметром является jmp_buf
, который должен быть инициализирован с помощью setjmp()
. Второй является целым ненулевым значением, которое setjmp()
возвращает в первоначальное окружение. Это сделано так, что код, подобный только что показанному, может различить установку окружения и прибытие путем нелокального перехода.
Стандарт С утверждает, что даже если
longjmp()
вызывается со вторым аргументом, равным 0, setjmp()
по-прежнему возвращает ненулевое значение. В таком случае она возвращает 1.
Возможность передать целое значение и вернуться обратно из
setjmp()
полезна; это позволяет коду уровня пользователя различать причину перехода. Например, gawk
использует эту возможность для обработки операторов break
и continue
внутри циклов. (Язык awk осознанно сделан похожим на С в своем синтаксисе для циклов, с использованием while
, do-while
, for
, break
и continue
.) Использование setjmp()
выглядит следующим образом (из eval.c
в дистрибутиве gawk
3.1.3):
507 case Node_K_while:
508 PUSH_BINDING(loop_tag_stack, loop_tag, loop_tag_valid);
509
510 stable_tree = tree;
511 while (eval_condition(stable_tree->lnode)) {
512 INCREMENT(stable_tree->exec_count);
513 switch (setjmp(loop_tag)) {
514 case 0: /* обычный не переход */
515 (void)interpret(stable_tree->rnode);
516 break;
517 case TAG_CONTINUE: /* оператор continue */
518 break;
519 case TAG_BREAK: /* оператор break */
520 RESTORE_BINDING(loop_tag_stack, loop_tag, loop_tag_valid);
521 return 1;
522 default:
523 cant_happen();
524 }
525 }
526 RESTORE_BINDING(loop_tag_stack, loop_tag, loop_tag_valid);
527 break;
Этот фрагмент кода представляет цикл
while
. Строка 508 управляет вложенными циклами посредством стека сохраненных переменных jmp_buf
. Строки 511–524 выполняют цикл while
(используя цикл С while
!). Строка 511 проверяет условие цикла. Если оно истинно, строка 513 выполняет switch
на возвращаемое значение setjmp()
. Если оно равно 0 (строки 514–516), строка 515 выполняет тело оператора. Однако, когда setjmp()
возвращает TAG_BREAK
или TAG_CONTINUE
, оператор switch
обрабатывает их соответствующим образом (строки 517–518 и 519–521 соответственно).
Оператор
break
на уровне awk
передает TAG_BREAK
функции longjmp()
, a continue
уровня awk
передает TAG_CONTINUE
. Снова из eval.c
с некоторыми пропущенными не относящимися к делу подробностями:
657 case Node_K_break:
658 INCREMENT(tree->exec_count);
/* ... */
675 longjmp(loop_tag, TAG_BREAK);
676 break;
677
678 case Node_K_continue:
679 INCREMENT(tree->exec_count);
/* ... */
696 longjmp(loop_tag, TAG_CONTINUE);
670 break;
Вы можете думать о
setjmp()
как об установке метки, а о longjmp()
как выполнении goto
с дополнительным преимуществом возможности сказать, откуда «пришел» код (по возвращаемому значению).
12.5.2. Обработка масок сигналов: sigsetjmp()
и siglongjmp()
По историческим причинам, которые, скорее всего, утомили бы вас до слез, стандарт С 1999 г. ничего не говорит о влиянии
setjmp()
и longjmp()
на состояние сигналов процесса, а POSIX явно констатирует, что их влияние на маску сигналов процесса (см. раздел 10.6 «Сигналы POSIX») не определено.
Другими словами, если программа изменяет свою маску сигналов процесса между первым вызовом
setjmp()
и вызовом longjmp()
, каково состояние маски сигналов процесса после longjmp()
? Та ли эта маска, когда была впервые вызвана setjmp()
? Или это текущая маска? POSIX явно утверждает, что «нет способа это узнать».
Чтобы сделать обработку маски сигналов процесса явной, POSIX ввел две дополнительные функции и один
typedef
:
#include /* POSIX */
int sigsetjmp(sigjmp_buf env, int savesigs); /* Обратите внимание:
sigjmp_buf, не jmp_buf! */
void siglongjmp(sigjmp_buf env, int val);
Главным отличием является аргумент
savesigs
функции sigsetjmp()
. Если он не равен нулю, текущий набор заблокированных сигналов сохраняется в env
вместе с остальным окружением, которое сохраняется функцией setjmp()
. siglongjmp()
с env
, в которой savesigs
содержала true, восстанавливает сохраненную маску сигналов процесса
ЗАМЕЧАНИЕ. POSIX также ясен в том, что если
savesigs
равен нулю (false), сохраняется ли маска сигналов процесса или восстанавливается, не определено, как в случае с setjmp()
/longjmp()
. Это, в свою очередь, предполагает, что если собираетесь использовать 'sigsetjmp(env, 0)
', вы также можете не беспокоиться: все дело в том, чтобы иметь контроль над сохранением и восстановлением маски сигналов процесса!
12.5.3. Важные предостережения
Есть несколько технических предостережений, о которых нужно знать.
Во-первых, поскольку сохранение и восстановление среды может быть беспорядочной машинно-зависимой задачей,
setjmp()
и longjmp()
могут быть макросами
Во-вторых, стандарт С ограничивает использование
setjmp()
следующими ситуациями.
• В качестве единственного контролирующего выражения в операторе цикла или условном операторе (
if
, switch
).
• В качестве одного операнда выражения сравнения (
==
, <
и т.д.), с целой константой в качестве другого операнда. Выражение сравнения может быть единственный контролирующим выражением цикла или условного оператора.
• В качестве операнда унарного оператора '
!
', причем результирующее выражение является единственным контролирующим выражением цикла или условного оператора.
• В качестве всего выражения оператора-выражения, возможно, приведенного к типу
void
. Например:
(void)setjmp(buf);
В-третьих, если вы хотите изменить локальную переменную в функции, которая вызывает
setjmp()
, после вызова и хотите, чтобы эта переменная сохранила свое последнее присвоенное после longjmp()
значение, нужно объявить эту переменную как volatile
. В противном случае все локальные переменные, не являющиеся volatile
и изменившиеся после того, как была первоначально вызвана setjmp()
, имеют неопределенные значения. (Обратите внимание, что сама переменная jmp_buf
не должна объявляться как volatile
.) Например:
1 /* ch12-setjmp.с --- демонстрирует setjmp()/longjmp() и volatile. */
2
3 #include
4 #include
5
6 jmp_buf env;
7
8 /* comeback --- выполнение longjmp */
9
10 void comeback(void)
11 {
12 longjmp(env, 1);
13 printf("This line is never printed\n");
14 }
15
16 /* main - вызов setjmp, действия с переменными, вывод значений */
17
18 int main(void)
19 {
20 int i = 5;
21 volatile int j = 6;
22
23 if (setjmp(env) == 0) { /* первый раз */
24 i++;
25 j++;
26 printf("first time: i = %d, j = %d\n", i, j);
27 comeback));
28 } else /* второй раз */
29 printf("second time: i = %d, j = %d\n", i, j);
30
31 return 0;
32 }
В этом примере сохранение своего значения ко второму вызову
printf()
гарантируется лишь
j (строка 21). Значение (строка 20) в соответствии со стандартом С 1999 г. не определено. Это может быть 6, может быть 5, а может даже какое-нибудь другое значение!
В-четвертых, как описано в разделе 12.5.2 «Обработка масок сигналов:
sigsetjmp()
и siglongjmp()
», стандарт С 1999 г. не делает никаких утверждений о влиянии, если оно есть, setjmp()
и longjmp()
на состояние сигналов программы. Если это важно, вам придется вместо них использовать sigsetjmp()
и siglongjmp()
.
В-пятых, эти процедуры содержат поразительные возможности для утечек памяти! Рассмотрим программу, в которой
main()
вызывает setjmp()
, а затем вызывает несколько вложенных функций, каждая из которых выделяет с помощью malloc()
динамическую память. Если наиболее глубоко вложенная функция делает longjmp()
обратно в main()
, указатели на динамическую память теряются. Взгляните на ch12-memleak.c
:
1 /* ch12-memleak.с --- демонстрирует утечки памяти с помощью setjmp()/longjmp(). */
2
3 #include
4 #include /* для определения ptrdiff_t в GLIBC */
5 #include
6 #include
7
8 jmp_buf env;
9
10 void f1(void), f2(void);
11
12 /* main --- утечка памяти с помощью setjmp() и longjmp() */
13
14 int main(void)
15 {
16 char *start_break;
17 char *current_break;
18 ptrdiff_t diff;
19
20 start_break = sbrk((ptrdiff_t)0);
21
22 if (setjmp(env) == 0) /* первый раз */
23 printf("setjmp called\n");
24
25 current_break = sbrk((ptrdiff_t) 0);
26
27 diff = current_break - start_break;
28 printf("memsize = %ld\n", (long)diff);
29
30 f1();
31
32 return 0;
33 }
34
35 /* f1 --- выделяет память, осуществляет вложенный вызов */
36
37 void f1(void)
38 {
39 char *p = malloc(1024);
40
41 f2();
42 }
43
44 /* f2 --- выделяет память, выполняет longjmp */
45
46 void f2(void)
47 {
48 char *p = malloc(1024);
49
50 longjmp(env, 1);
51 }
Эта программа устанавливает бесконечный цикл, используя
setjmp()
и longjmp()
. Строка 20 использует для нахождения текущего начала кучи sbrk()
(см. раздел 3.2.3 «Системные вызовы: brk()
и sbrk()
»), а затем строка 22 вызывает setjmp()
. Строка 25 получает текущее начало кучи; это место каждый раз изменяется, поскольку longjmp()
повторно входит в код. Строки 27–28 вычисляют, сколько было выделено памяти, и выводят это количество. Вот что происходит при запуске:
$ ch12-memleak /* Запуск программы */
setjmp called
memsize = 0
memsize = 6372
memsize = 6372
memsize = 6372
memsize = 10468
memsize = 10468
memsize = 14564
memsize = 14564
memsize = 18660
memsize = 18660
...
Память утекает из программы, как через решето. Она работает до тех пор, пока не будет прервана от клавиатуры или пока не закончится память (в этом случае образуется основательный дамп ядра).
Каждая из функций
f1()
и f2()
выделяют память, a f2()
выполняет longjmp()
обратно в main()
(строка 51). Когда это происходит, локальные указатели (строки 39 и 48) на выделенную память пропали! Такие утечки памяти может оказаться трудно отследить, поскольку часто выделяются небольшие размеры памяти, и как таковые, они могут оставаться незамеченными в течение ряда лет[128].
Этот код явно патологический, но он предназначен для иллюстрации нашей мысли:
setjmp()
и longjmp()
могут вести к трудно обнаруживаемым утечкам памяти. Предположим, что f1()
правильно вызвал free()
. Было бы далеко неочевидно, что память никогда не будет освобождена. В более крупной и более реалистичной программе, в которой longjmp()
мог быть вызван лишь посредством if
, найти такую утечку становится даже еще труднее.
Таким образом, при наличии
setjmp()
и longjmp()
динамическая память должна управляться посредством глобальных переменных, а у вас должен быть код, который обнаруживает вход через longjmp()
(посредством проверки возвращаемого значения setjmp()
). Такой код должен затем освободить динамически выделенную память, которая больше не нужна.
В-шестых,
longjmp()
и siglongjmp()
не следует использовать из функций, зарегистрированных посредством atexit()
(см. раздел 9.1.5.3 «Функции завершения»).
В-седьмых,
setjmp()
и longjmp()
могут оказаться дорогими операциями на машинах с множеством регистров.
При наличии всех этих проблем вы должны строго рассмотреть дизайн своей программы. Если вам не нужно использовать
setjmp()
и longjmp()
, то, может, стоит обойтись без их использования. Однако, если их использование является лучшим способом структурировать свою программу, продолжайте и используйте их, но делайте это осмотрительно.
12.6. Псевдослучайные числа
Многим приложениям нужны последовательности случайных чисел. Например, игровые программы, имитирующие бросание костей, раздачу карт или вращение барабанов игровой машины, нуждаются в возможности случайного выбора одного из возможных значений. (Подумайте о программе
fortune
, содержащей большую коллекцию афоризмов; каждый раз при запуске она «случайно» выдает новое высказывание.) Многие криптографические алгоритмы также требуют наличия случайных чисел «высокого качества». В данном разделе описываются различные способы получения последовательностей случайных чисел.
ЗАМЕЧАНИЕ. Природа случайности, генерация случайных чисел и их «качество» являются обширными темами, выходящими за рамки данной книги. Мы предоставляем введение в доступные функции API, но это все, что мы можем сделать Другие источники с более подробной информацией см в разделе 12.9 «Рекомендуемая литература»
Компьютеры по своему строению являются детерминистическими. Одно и то же вычисление с одними и теми же входными данными всегда должно давать одни и те же результаты. Соответственно, они не годятся для генерации истинно случайных чисел, то есть последовательностей чисел, в которых каждое число в последовательности полностью независимо от числа (или чисел), идущих перед ним. Вместо этого разновидности чисел, обычно используемых на программном уровне, называются псевдослучайными числами. То есть в любой данной последовательности номера выглядят независимыми друг от друга, но сама последовательность в целом повторяющаяся. (Эта повторяемость может быть ценным качеством; она обеспечивает детерминизм для программы в целом.)
Многие методы предоставления последовательностей псевдослучайных чисел работают посредством осуществления каждый раз одного и того же вычисления с начальным значением (seed). Сохраненное начальное значение затем обновляется для использования в следующий раз. API предоставляет способ указания нового начального значения. Каждое начальное значение дает одну и ту же последовательность псевдослучайных чисел, хотя различные начальные числа дают (должны давать) различные последовательности.
12.6.1. Стандартный С: rand()
и srand()
Стандартный С определяет две связанные функции для псевдослучайных чисел.
#include /* ISO С */
int rand(void);
void srand(unsigned int seed);
rand()
каждый раз после вызова возвращает псевдослучайное число в диапазоне от 0 до RAND_MAX
(включительно, насколько мы можем судить по стандарту C99). Константа RAND_MAX
должна быть по крайней мере 32 767; она может быть больше.
srand()
дает генератору случайных чисел в качестве начального значения seed
. Если srand()
никогда не вызывался приложением, rand()
ведет себя так, как если бы seed был равен 1.
Следующая программа,
ch12-rand.c
, использует rand()
для вывода граней игральных костей.
1 /* ch12-rand.c --- генерирует игральные кости, используя rand(). */
2
3 #include
4 #include
5
6 char *die_faces[] = { /* Управляет ASCII графика! */
7 " ",
8 " * ", /* 1 */
9 " ",
10
11 " ",
12 " * * ", /* 2 */
13 " ",
14
15 " ",
16 " * * * ", /* 3 */
17 " ",
18
19 " * * ",
20 " ", /* 4 */
21 " * * ",
22
23 " * * ",
24 " * ", /* 5 */
25 " * * ",
26
27 " * * * ",
28 " ", /* 6 */
29 " * * * ",
30 };
31
32 /* main --- выводит N различных граней костей */
33
34 int main(int argc, char **argv)
35 {
36 int nfaces;
37 int i, j, k;
38
39 if (argc !=2) {
40 fprintf(stderr, "usage: %s number-die-faces\n", argv[0]);
41 exit(1);
42 }
43
44 nfaces = atoi(argv[1]);
45
46 if (nfaces <= 0) {
47 fprintf(stderr, "usage: %s number-die-faces\n", argv[0]);
48 fprintf(stderr, "\tUse a positive number!\n");
49 exit(1);
50 }
51
52 for (i = 1; i <= nfaces; i++) {
53 j = rand() % 6; /* force to range 0 <= j <= 5 */
54 printf("+-------+\n" );
55 for (k = 0; k < 3; k++)
56 printf("|%s|\n", die_faces[(j * 3) + k]);
57 printf ("+-------+\n\n");
58 }
59
60 return 0;
61 }
Эта программа использует простую ASCII-графику для распечатывания подобия грани игральной кости. Вы вызываете ее с числом граней для вывода. Это вычисляется в строке 44 с помощью
atoi()
. (В общем, atoi()
следует избегать в коде изделия, поскольку она не осуществляет проверку на ошибки или переполнение, также как не проверяет вводимые данные.)
Ключевой является строка 53, которая преобразует возвращаемое значение
rand()
в число от нуля до пяти, используя оператор остатка, %
. Значение 'j * 3
' действует в качестве начального индекса массива die_faces
для трех строк, составляющих каждую грань кости. Строки 55 и 56 выводят саму грань. При запуске появляется вывод наподобие этого:
$ ch12-rand 2 /* Вывести две кости */
+-------+
| |
| * * |
| |
+-------+
+-------+
| * * |
| * |
| * * |
+-------+
Интерфейс
rand()
восходит еще к V7 и PDP-11. В частности, на многих системах результатом является лишь 16-разрядное число, что значительно ограничивает диапазон чисел, которые могут быть возвращены. Более того, используемый им алгоритм по современным стандартам считается «слабым». (Версия rand()
GLIBC не имеет этих проблем, но переносимый код должен быть написан со знанием того, что rand()
не является лучшим API для использования.)
ch12-rand.c
использует для получения значения в определенном интервале простую методику: оператор %
. Эта методика использует младшие биты возвращенного значения (как при десятичном делении, когда остаток отделения на 10 или 100 использует одну или две младшие десятичные цифры). Оказывается, исторический генератор rand()
производил лучшие случайные значения в средних и старших битах по сравнению с младшими битами. Поэтому, если вы должны использовать rand()
, постарайтесь избежать младших битов. Справочная страница GNU/Linux rand(3) цитирует «Числовые рецепты на С»[129], которая рекомендует эту методику:
j = 1+ (int)(10.0*rand()/(RAND_MAX+1.0)); /* для числа от 1 до 10 */
12.6.2. Функции POSIX: random()
и srandom()
BSD 4.3 ввело random() и сопровождающие ее функции. Эти функции используют намного более подходящий генератор случайных чисел, который возвращает 31-разрядное значение. Теперь они входят в расширение XSI, стандартизованное POSIX:
#include /* XSI */
long random(void);
void srandom(unsigned int seed);
char *initstate(unsigned int seed, char *state, size_t n);
char *setstate(char *state);
Первые две функции близко соответствуют
rand()
и srand()
и могут использоваться сходным образом. Однако, вместо одного начального значения, которое дает последовательность псевдослучайных чисел, эти функции используют начальное значение вместе с массивом состояния: массивом байтов, который хранит сведения о состоянии для вычисления псевдослучайных чисел. Последние две функции дают возможность управлять массивом состояния.
long random(void);
Возвращает число в диапазоне от 0 до 231-1. (Хотя справочная страница GNU/Linux random(3) говорит между 0 и
RAND_MAX
, это верно лишь для систем GLIBC, где RAND_MAX
равен 231-1. На других системах RAND_MAX
может быть меньше. POSIX явно называет диапазон от 0 до 231-1.)
void srandom(unsigned int seed);
Устанавливает начальное число. Если
srandom()
никогда не вызывается, по умолчанию используется 1.
char *initstate(unsigned int seed, char *state, size_t n);
Инициализирует массив
state
информацией для использования при генерации случайных чисел, seed
является начальным значением, как для srandom()
, а n
является числом байтов в массиве state
.
n
должен равняться одному из значений 8, 32, 64, 128 или 256. Большие значения дают лучшие последовательности случайных чисел. Значения меньше 8 заставляют random()
использовать простой генератор случайных чисел, сходный с rand()
. Значения больше 8, не равные одному из значений в списке, округляются до ближайшего подходящего значения.
char *setstate(char *state);
Устанавливает внутреннее состояние в соответствии с массивом
state
, который должен быть инициализирован посредством initstate()
. Это позволяет переключаться по желанию между различными состояниями, предоставляя множество генераторов случайных чисел.
Если
initstate()
и setstate()
никогда не вызывались, random()
использует массив внутреннего состояния размером 128.
Массив
state
непрозрачен; вы инициализируете его с помощью initstate()
и передается функции random()
посредством setstate()
, но в другом отношении вам не нужно заглядывать в него. Если вы используете initstate()
и setstate()
. srandom()
вызывать не нужно, поскольку начальное значение включено в информацию о состоянии. ch12-random.c
использует эти процедуры вместо rand()
. Используется также обычная методика, которая заключается в использовании в качестве начального значения генератора случайных чисел времени дня, добавленного к PID.
1 /* ch12-random.c --- генерация вращения костей с использованием random(). */
2
3 #include
4 #include
5 #include
6 #include
7
8 char *die_faces[] = { /* Управляет ASCII графика! */
/* ... как раньше ... */
32 };
33
34 /* main --- выводит N различных граней кубиков */
35
36 int main(int argc, char **argv)
37 {
38 int nfaces;
39 int i, j, k;
40 char state[256];
41 time_t now;
42
/* ... проверка args, вычисление nfaces, как раньше ... */
55
56 (void)time(&now); /* В качестве начального значения используются время дня и PID */
57 (void) initstate((unsigned int)(now + getpid()), state, sizeof state);
58 (void)setstate(state);
59
60 for (i = 1; i <= nfaces; i++) {
61 j = random() % 6; /* использовать диапазон 0 <= j <= 5 */
62 printf("+-------+\n");
63 for (k = 0; k < 3; k++)
64 printf("|%s|\n", die_faces[(j * 3) + k]);
65 printf("+-------+\n\n");
66 }
67
68 return 0;
69 }
Включение PID в состав начального значения гарантирует, что вы получите различные результаты, даже если две программы будут запушены в течение одной и той же секунды.
Поскольку она создает последовательности случайных чисел лучшего качества,
random()
является более предпочтительной по сравнению с rand()
, и GNU/Linux и все современные системы Unix ее поддерживают.
12.6.3. Особые файлы /dev/random
и /dev/urandom
Как
rand()
, так и srandom()
являются генераторами псевдослучайных чисел. Их вывод для одного и того же начального значения является воспроизводимой последовательностью чисел. Некоторым приложениям, подобным криптографическим, необходимо, чтобы их случайные числа были действительно (более) случайными. С этой целью ядро Linux, также как различные BSD и коммерческие Unix системы предусматривают специальные файлы устройств, которые предоставляют доступ к «энтропийному пулу» случайных битов, которые ядро собирает от физических устройств и других источников. Из справочной страницы random(4):
/dev/random
[Байты, прочитанные из этого файла, находятся] внутри предполагаемого числа шумовых битов в энтропийном пуле,
/dev/random
должен подходить для использования в случаях, когда необходим высокий уровень случайности, таких, как одноразовая генерация ключа или блока памяти. Когда энтропийный пул пустой, чтение /dev/random
будет блокироваться до тех пор, пока не будет собран дополнительный шум окружения.
/dev/urandom
[Это устройство будет] возвращать столько байтов, сколько затребовано. В результате, если нет достаточной энтропии в энтропийном пуле, возвращаемые значения теоретически уязвимы для криптографической атаки алгоритма, использованного драйвером. Знание того, как это сделать, недоступно в современной не секретной литературе, но теоретически возможно существование подобной атаки. Если для вашего приложения это представляет проблему, вместо этого используйте
/dev/random
.
Для большинства приложений чтения из
/dev/urandom
должно быть вполне достаточно. Если вы собираетесь написать криптографические алгоритмы высокого качества, следует сначала почитать о криптографии и случайности; не полагайтесь здесь на поверхностное представление! Вот еще одна наша программа для бросания костей, использующая /dev/urandom
:
1 /* ch12-devrandom.с --- генерирует бросание костей, используя /dev/urandom. */
2
3 #include
4 #include
5 #include
6
7 char *die_faces[] = { /* Управляет ASCII графика! */
/* ... как ранее ... */
31 };
32
33 /* myrandom --- возвращает данные из /dev/urandom в виде unsigned long */
34
35 unsigned long myrandom(void)
36 {
37 static int fd = -1;
38 unsigned long data;
39
40 if (fd == -1)
41 fd = open("/dev/urandom", O_RDONLY);
42
43 if (fd == -1 || read(fd, &data, sizeof data) <= 0)
44 return random(); /* отступить */
45
46 return data;
47 }
48
49 /* main --- вывести N различных граней кубиков */
50
51 int main(int argc, char **argv)
52 {
53 int nfaces;
54 int i, j, k;
55
/* ...проверка args, вычисление nfaces, как ранее... */
68
69 for (i = 1; i <= nfaces; i++) {
70 j = myrandom() % 6; /* обеспечить диапазон 0 <= j <= 5 */
71 printf("+-------+\n");
72 for (k = 0; k < 3; k++)
73 printf("|%s|\n", die_faces[(j * 3) + k]);
74 printf("+-------+\n");
75 putchar('\n');
76 }
77
78 return 0;
79 }
Строки 35–47 предоставляют интерфейс вызова функции для
/dev/urandom
, читая каждый раз данные unsigned long
. Издержками является один дескриптор файла, который остается открытым в течение жизни программы.
12.7. Расширения метасимволов
Три набора функции возрастающей сложности предусматривают возможность сопоставления с шаблонами групповых символов оболочки. Многим программам нужны такие библиотечные функции. Одним примером является
find
: 'find . -name '*.с' -print
'. Другим примером является опция --exclude
во многих программах, которая принимает шаблон файлов с групповыми символами для исключения из того или иного действия. В данном разделе по очереди рассматривается каждый набор функций.
12.7.1. Простое сопоставление с шаблоном: fnmatch()
Мы начинаем с функции
fnmatch()
(«filename match» — сопоставление имени файла»).
#include /* POSIX */
int fnmatch(const char *pattern, const char *string, int flags);
Эта функция сопоставляет
string
с pattern
, который является обычным шаблоном групповых символов оболочки. Значение флагов (которое вскоре будет описано) изменяет поведение функции. Возвращаемое значение равно 0, если string
соответствует pattern
, FNM_NOMATCH
, если не соответствует, и ненулевое значение, если возникла ошибка. К сожалению, POSIX не определяет каких-либо специфических ошибок; соответственно, вы можете лишь сказать, что что-то пошло не так, но не можете сказать, что.
Переменная
flags
является побитовым ИЛИ одного или более флагов, перечисленных в табл. 12.1.
Таблица 12.1. Значения флагов для
fnmatch()
Флаг
Только GLIBC
Значение
FNM_CASEFOLD
√
Сопоставление с учетом регистра
FNM_FILE_NAME
√
Синоним GNU для FNM_PATHNAME
FNM_LEADING_DIR
√
Флаг для внутреннего использования GLIBC; не используйте его в своих программах. Подробности см. в fnmatch(3)
FNM_NOESCAPE
Обратный слеш является обычным символом, а не знаком перехода
FNM_PATHNAME
Слеш в string
должен соответствовать слешу в pattern
, он не может быть подставлен через *
, ?
или '[...]
'
FNM_PERIOD
Начальная точка в string
подходит, лишь если в pattern
также есть начальная точка. Точка должна быть первым символом в string
. Однако, если также установлен FNM_PATHNAME
, точка, которая идет за слешем, также рассматривается как начальная
fnmatch()
работает со строками из любого источника; сопоставляемые строки не обязательно должны быть действительными именами файлов. Хотя на практике fnmatch()
используется в коде, читающем каталог с помощью readdir()
(см раздел 5.3.1 «Базовое чтение каталогов»):
struct dirent dp;
DIR *dir;
char pattern[100];
/* ...заполнить шаблон, открыть каталог, проверить ошибки... */
while ((dp = readdir(dir)) != NULL) {
if (fnmatch(pattern, dir->d_name, FNM_PERIOD) == 0)
/* имя файла соответствует шаблону */
else
continue; /* не соответствует */
}
GNU
ls
использует fnmatch()
для реализации своей опции --ignore
. Вы можете предоставить несколько игнорируемых шаблонов (с помощью нескольких опций). ls
сопоставляет каждое имя файла со всеми шаблонами. Она делает это с помощью функции file_interesting()
в ls.с
:
2269 /* Возвращает не ноль, если файл в 'next' должен быть перечислен. */
2270
2271 static int
2272 file_interesting(const struct dirent *next)
2273 {
2274 register struct ignore_pattern* ignore;
2275
2276 for (ignore = ignore_patterns; ignore; ignore = ignore->next)
2277 if (fnmatch(ignore->pattern, next->d_name, FNM_PERIOD) == 0)
2278 return 0;
2279
2280 if (really_all_files
2281 || next->d_name[0] !=
2282 || (all_files
2283 && next->d_name[1] != '\0 '
2284 && (next->d_name[1] || next->d_name[2] != '\0')))
2285 return 1;
2286
2287 return 0;
2288 }
Цикл в строках 2276–2278 сопоставляет имя файла со списком шаблонов для игнорируемых файлов. Если один из шаблонов подходит, файл не интересен и
file_interesting()
возвращает false (то есть 0).
Переменная
all_files
соответствует опции -А
, которая показывает файлы, имена которых начинаются с точки, но не являются '.
' и '..
'. Переменная really_all_files
соответствует опции -а
, которая предполагает -А
, а также показывает '.
' и '..
'. При наличии таких сведений, условие в строках 228–2284 может быть представлено следующим псевдокодом:
if (/* показать все файлы независимо от их имени (-а) */
OR /* первый символ имени не точка */
OR (/* показать файлы с точкой (-А) */
AND /* в имени файла несколько символов */
AND (/* второй символ не точка */
OR /* третий символ не завершает имя */)))
return TRUE;
ЗАМЕЧАНИЕ.
fnmatch()
может оказаться дорогостоящей функцией, если она используется в локали с многобайтным набором символов. Обсудим многобайтные наборы символов в разделе 13.4 «Можете произнести это для меня по буквам?»
12.7.2. Раскрытие имени файла: glob()
и globfree()
Функции
glob()
и globfree()
более разработанные, чем fnmatch()
:
#include /* POSIX */
int glob(const char *pattern, int flags,
int (*errfunc)(const char *epath, int eerrno), glob_t *pglob);
void globfree(glob_t *pglob);
Функция
glob()
осуществляет просмотр каталога и сопоставление с шаблонами, возвращая список всех путей, соответствующих pattern
. Символы подстановки могут быть включены в нескольких местах пути, а не только в качестве последнего компонента (например, '/usr/*/*.so
'). Аргументы следующие:
const char *pattern
Шаблон для раскрывания.
int flags
Флаги, управляющие поведением
glob()
, вскоре будут описаны.
int (*errfunc)(const char *epath, int eerrno)
Указатель на функцию для использования при сообщениях об ошибках. Это значение может равняться
NULL
. Если нет и если (*errfunc)()
возвращает ненулевое значение или в flags
установлен GLOB_ERR
, glob()
прекращает обработку. Аргументами (*errfunc)()
являются путь, вызвавший проблему, и значение errno, установленное функциями opendir()
, readdir()
или stat()
.
glob_t *pglob
Указатель на структуру
glob_t
, использующуюся для хранения результатов. Структура glob_t
содержит список путей, которые выдает glob()
:
typedef struct { /* POSIX */
size_t gl_pathc; /* Число найденных подходящих путей */
char **gl_pathv; /* Список подходящих путей */
size_t gl_offs; /* Слоты для резервирования в gl_pathv */
} glob_t;
size_t gl_pathc
Число путей, которые подошли.
char **gl_pathv
Массив подходящих путей.
gl_pathv[gl_pathc]
всегда равен NULL
.
size_t gl_offs
«Зарезервированные слоты» в
gl_pathv
. Идея заключается в резервировании слотов спереди от gl_pathv
для заполнения их приложением впоследствии, как в случае с именем команды и опциями. Список затем может быть передан непосредственно execv()
или execvp()
(см. раздел 9.1.4 «Запуск новой программы: семейство exec()
»). Зарезервированные слоты устанавливаются в NULL
. Чтобы все это работало, в flags
должен быть установлен GLOB_DOOFFS
.
В табл. 12.2 перечислены стандартные флаги для
glob()
.
Таблица 12.2. Флаги для
glob()
Флаг
Значение
GLOB_APPEND
Добавить результаты текущего вызова к предыдущим
GLOB_DOOFFS
Зарезервировать места gl_offs
спереди в gl_pathv
GLOB_MARK
Добавлять символ / в конец каждого имени, которое обозначает каталог
GLOB_NOCHECK
Если шаблон не соответствует имени какого-нибудь файла, вернуть его без изменений
GLOB_NOESCAPE
Рассматривать обратный слеш как обычный символ. Это делает невозможным обозначать метасимволы подстановок
GLOB_NOSORT
Не сортировать результаты, по умолчанию они сортируются
GLIBC версия структуры
glob_t
содержит дополнительные члены:
typedef struct { /* GLIBC */
/* Компоненты POSIX: */
size_t gl_pathc; /* Число подходящих путей */
char **gl_pathv; /* Список подходящих путей */
size_t gl_offs; /* Резервируемые в gl_pathv слоты */
/* Компоненты GLIBC: */
int gl_flags; /* Копия флагов, дополнительные флаги GLIBC */
void (*gl_closedir)(DIR *); /* Частная версия closedir() */
struct dirent *(*gl_readdir)(DIR *); /* Частная версия readdir)) */
DIR *(*gl_opendir)(const char *); /* Частная версия opendir)) */
int (*gl_lstat)(const char *, struct stat *);
/* Частная версия lstat() */
int (*gl_stat)(const char *, struct stat *); /* Частная версия stat() */
} glob_t;
Члены структуры следующие:
int gl_flags
Копия флагов. Включает также
GLOB_MAGCHAR
, если pattern
включал какие-либо метасимволы.
void (*gl_closedir)(DIR *)
Указатель на альтернативную версию
closedir()
.
struct dirent *(*gl_readdir)(DIR *)
Указатель на альтернативную версию
readdir()
.
DIR *(*gl_opendir)(const char *)
Указатель на альтернативную версию
opendir()
.
int (*gl_lstat)(const char *, struct stat*)
Указатель на альтернативную версию
lstat()
.
int (*gl_stat)(const char*, struct stat*)
Указатель на альтернативную версию
stat()
.
Указатели на альтернативные версии стандартных функций предназначены главным образом для использования в реализации GLIBC; крайне маловероятно, что вы когда-нибудь их используете. Поскольку GLIBC предусматривает поле
gl_flags
и дополнительные значения флагов, справочная страница и руководство Info документируют оставшуюся часть структуры GLIBC glob_t
. В табл. 12.3 перечислены дополнительные флаги.
Таблица 12.3. Дополнительные флаги GLIBC для
glob()
Флаг
Значение
GLOB_ALTDIRFUNC
Использовать для доступа к каталогам альтернативные функции (см. текст)
GLOB_BRACE
Выполнить раскрытие фигурных скобок в стиле csh
и Bash.
GLOB_MAGCHAR
Вставить gl_flags
, если были найдены метасимволы.
GLOB_NOMAGIC
Вернуть шаблон, если он не содержит метасимволов
GLOB_ONLYDIR
По возможности сопоставлять лишь каталоги. См. текст.
GLOB_PERIOD
Разрешить соответствие метасимволов наподобие *
и ?
начальной точке
GLOB_TILDE
Выполнить раскрывание тильды в стиле оболочки.
GLOB_TILDE_CHECK
Подобно GLOB_TILDE
, но если есть проблемы с указанным домашним каталогом, вернуть GLOB_NOMATCH
вместо помещения pattern
в список.
Флаг
GLOB_ONLYDIR
действует в качестве подсказки реализации, потому что вызывающий интересуется лишь каталогами. Главным его предназначением является использование другими функциями в GLIBC, а вызывающий по-прежнему должен быть готов обрабатывать файлы, не являющиеся каталогами. Вам не следует использовать этот флаг в своих программах.
glob()
может быть вызвана более одного раза: при первом вызове флаг GLOB_APPEND
не должен быть указан, при всех последующих вызовах он должен быть указан. Вы не можете между вызовами изменять gl_offs
, а если вы изменили какие-нибудь значения в gl_pathv
или gl_pathc
, нужно их восстановить перед последующим вызовом glob()
.
Возможность многократного вызова
glob()
позволяет накапливать результаты в одном списке. Это довольно практично, приближается к мощным возможностям раскрывания групповых символов оболочки, но на уровне языка программирования С.
glob()
возвращает 0, если не было проблем, или одно из значений из табл. 12.4, если были.
Таблица 12.4. Возвращаемые
glob()
значения
Флаг
Значение
GLOB_ABORTED
Просмотр остановлен раньше времени, поскольку был установлен GLOB_ERR
или функция (*errfunc)()
возвратила ненулевой результат
GLOB_NOMATCH
Ни одно имя файла не соответствовало pattern
, а флаг GLOB_NOCHECK
не был установлен
GLOB_NOSPACE
Была проблема с выделением динамической памяти
globfree()
освобождает всю память, которую динамически выделила glob()
Следующая программа, ch12-glob.с
, демонстрирует glob()
:
1 /* ch12-glob.c --- демонстрирует glob(). */
2
3 #include
4 #include
5 #include
6
7 char *myname;
8
9 /* globerr --- выводит сообщение об ошибке для glob() */
10
11 int globerr(const char *path, int eerrno)
12 {
13 fprintf(stderr, "%s: %s: %s\n", myname, path, strerror(eerrno));
14 return 0; /* let glob() keep going */
15 }
16
17 /* main() --- раскрывает символы подстановки в командной строке и выводит результаты */
18
19 int main(int argc, char **argv)
20 {
21 int i;
22 int flags = 0;
23 glob_t results;
24 int ret;
25
26 if (argc == 1) {
27 fprintf(stderr, "usage: %s wildcard ...\n", argv[0]);
28 exit(1);
29 }
30
31 myname = argv[0]; /* для globerr() */
32
33 for (i = 1; i < argc; i++) {
34 flags |= (i > 1 ? GLOB_APPEND : 0);
35 ret = glob(argv[i], flags, globerr, &results);
36 if (ret != 0) {
37 fprintf(stderr, "%s: problem with %s (%s),
38 stopping early\n", myname, argv[i],
39 /* опасно: */ (ret == GLOB_ABORTED ? "filesystem problem" :
40 ret == GLOB_NOMATCH ? "no match of pattern" :
41 ret == GLOB_NOSPACE ? "no dynamic memory" :
42 "unknown problem"));
43 break;
44 }
45 }
46
47 for (i = 0; i < results.gl_pathc; i++)
48 printf("%s\n", results.gl_pathv[i]);
49
50 globfree(&results);
51 return 0;
52 }
Строка 7 определяет
myname
, которая указывает на имя программы; эта переменная для сообщений об ошибках от globerr()
, определенной в строках 11–15.
Строки 33–45 являются основой программы. Они перебирают в цикле шаблоны, приведенные в командной строке, вызывая для каждого
glob()
для добавления к списку результатов. Большую часть цикла составляет обработка ошибок (строки 36–44). Строки 47–48 выводят результирующий список, а строки 50–51 проводят завершающую очистку и возвращаются.
Строки 39–41 не являются хорошими; нужно было использовать отдельную функцию, преобразующую целые константы в строки; мы сделали это главным образом ради экономии места. Код наподобие этого может быть сносным для небольших программ, но более крупные должны использовать функцию.
Если вы подумаете о работе, происходящей под капотом (открытие и чтение каталогов, сопоставление шаблонов, динамическое выделение памяти для увеличения списка, сортировка списка), можете качать ценить, как много для вас делает
glob()
! Вот некоторые результаты:
$ ch12-glob '/usr/lib/x*.so' '../../*.texi'
/usr/lib/xchat-autob5.so
/usr/lib/xchat-autogb.so
../../00-preface.texi
../../01-intro.texi
../../02-cmdline.texi
../../03-memory.texi
...
Обратите внимание, что нам пришлось взять аргументы в кавычки, чтобы предотвратить их разворачивание оболочкой!
Универсализация имен? Что это?
В былые времена, около V6 Unix, для осуществления разворачивания символов подстановки оболочка использовала за кулисами отдельную программу. Эта программа называлась
/etc/glob
, и согласно исходному коду V6[130], имя «glob» было сокращением от «global».
Таким образом глагол «to glob» проник в лексикон Unix со значением «осуществлять разворачивание символов подстановки». Это, в свою очередь, дает нам имена функций
glob()
и globfree()
. Так что обычно недооцениваемое чувство юмора, время от времени проглядывающее из руководства Unix, все еще живо, официально сохраненное в стандарте POSIX. (Можете ли вы представить кого-нибудь в IBM в 70-х или 80-х годах XX века, называющего системную процедуру glob()
?)
12.7.3. Разворачивание слов оболочкой: wordexp()
и wordfree()
Многие члены комитета POSIX чувствовали, что
glob()
делает недостаточно: им нужна была библиотечная процедура, способная делать все, что может делать оболочка разворачивание тильды ('echo ~arnold
'), разворачивание переменных оболочки ('echo $HOME
') и подстановку команд ('echo $(cd ; pwd)
'). Многие другие чувствовали, что glob()
не подходила для этой цели. Чтобы «удовлетворить» каждого, POSIX предоставляет две дополнительные функции, которые делают все:
#include /* POSIX */
int wordexp(const char *words, wordexp_t *pwordexp, int flags);
void wordfree(wordexp_t *wordexp);
Эти функции работают сходным с
glob()
и globfree()
образом, но со структурой wordexp_t
:
typedef struct {
size_t we_wordc; /* Число подходящих слов */
char **we_wordv; /* Список развернутых слов */
size_t we_offs; /* Резервируемые в we_wordv слоты */
} wordexp_t;
Члены структуры полностью аналогичны описанным ранее для
glob_t
; мы не будем здесь повторять все описание.
Как и для
glob()
, поведение wordexp()
управляется несколькими флагами. Флаги перечислены в табл. 12.5.
Таблица 12.5. Флаги для
wordexp()
Константа
Значение
WRDE_APPEND
Добавить результаты текущего вызова к предыдущим
WRDE_DOOFFS
Зарезервировать we_offs
мест в начале we_wordv
WRDE_NOCMD
Запретить подстановку команд
WRDE_REUSE
Повторно использовать память, на которую указывает we_wordv
WRDE_SHOWERR
Не молчать при возникновении во время разворачивания ошибок
WRDE_UNDEF
Неопределенные переменные оболочки должны вызывать ошибку
Возвращаемое значение равно 0, если все прошло хорошо, или одно из значений из табл. 12.6, если нет.
Таблица 12.6. Возвращаемые значения ошибок для
wordexp()
Константа
Значение
WRDE_BADCHAR
Метасимвол (конец строки, '|', &, ;, <, >, (, ), {, или }) в недопустимом месте
WRDE_BADVAL
Переменная не определена при установленном WRDE_UNDEF
WRDE_CMDSUB
Попытка подстановки команды при установленном WRDE_NOCMD
WRDE_NOSPACE
Была проблема с выделением динамической памяти
WRDE_SYNTAX
Синтаксическая ошибка оболочки.
Мы оставляем вам в качестве упражнения (см. далее) модификацию
ch12-glob.c
для использования wordexp()
и wordfree()
. Вот наша версия в действии:
$ ch12-wordexp 'echo $HOME' /* Развертывание переменных оболочки */
echo
/home/arnold
$ ch12-wordexp 'echo $HOME/*.gz' /* Переменные и символы подстановки */
echo
/home/arnold/48000.wav.gz
/home/arnold/ipmasq-HOWTO.tar.gz
/home/arnold/rc.firewall-examples.tar.gz
$ ch12-wordexp 'echo ~arnold' /* Развертывание тильды */
echo
/home/arnold
$ ch12-wordexp 'echo ~arnold/.p*' /* Тильда и символы подстановки */
echo
/home/arnold/.postitnotes
/home/arnold/.procmailrc
/home/arnold/.profile
$ ch12-wordexp "echo '~arnold/.p*'" /* Кавычки работают */
echo
~arnold/.p*
12.8. Регулярные выражения
Регулярные выражения являются способом описания текстовых шаблонов для сопоставления. Если вы вообще сколько-нибудь использовали GNU/Linux или Unix, вы без сомнения знакомы с регулярными выражениями: они являются фундаментальной частью инструментария программиста Unix. Они неотъемлемы от таких повседневных программ, как
grep
, egrep
, sed
, awk
, Perl, а также редакторы ed
, vi
, vim
и Emacs. Если вы вообще не знакомы с регулярными выражениями, мы рекомендуем ознакомиться с некоторыми из книг или URL, указанных в разделе 12.9 «Рекомендуемая литература».
POSIX определяет два вида регулярных выражений: базовый и расширенный. Программы типа
grep
, sed
и строчный редактор ed
используют базовые регулярные выражения. Программы типа egrep
и awk
используют расширенные регулярные выражения. Следующие функции дают вам возможность использовать в своих программах любой вид.
#include /* POSIX */
#include
int regcomp(regex_t *preg, const char *regex, int cflags);
int regexec(const regex_t *preg, const char *string, size_t nmatch,
regmatch_t pmatch[], int eflags);
size_t regerror(int errcode, const regex_t *preg,
char *errbuf, size_t errbuf_size);
void regfree(regex_t *preg);
Чтобы сопоставить регулярное выражение, нужно сначала откомпилировать строчную версию регулярного выражения. Компиляция преобразует регулярное выражение во внутренний формат. Затем откомпилированная форма исполняется для строки для проверки, совпадает ли она с первоначальным регулярным выражением. Функции следующие.
int regcomp(regex_t *preg, const char *regex, int cflags)
Компилирует регулярное выражение
regex
во внутреннее представление, сохраняя его в структуре regex_t
, на которую указывает preg
. cflags
контролирует процесс компиляции; ее значение равно 0 или побитовому ИЛИ одного или более флагов из табл. 12.7
int regexec(const regex_t *preg, const char *string, size_t nmatch,
regmatch_t pmatch[], int eflags)
Выполняет откомпилированное регулярное выражение в
*preg
в строке string eflags
контролирует способ выполнения; ее значение равно 0 или побитовому ИЛИ одного или более флагов из табл. 12.8. Вскоре мы обсудим другие аргументы.
size_t regerror(int errcode, const regex_t *preg,
char *errbuf, size_t errbuf_size)
Преобразует ошибку, возвращенную
regcomp()
или regexec()
, в удобочитаемую строку.
void regfree(regex_t *preg)
Освобождает динамическую память, используемую откомпилированным регулярным выражением в
*preg
.
Заголовочный файл
определяет ряд флагов. Некоторые используются с regcomp()
; другие используются с regexec()
. Однако, все они начинаются с префикса 'REG_
'. В табл. 12.7 перечислены флаги для компиляции регулярных выражений с помощью regcomp()
.
Таблица 12.7. Флаги для
regcomp()
Константа
Значение
REG_EXTENDED
Использовать расширенные регулярные выражения. По умолчанию используются базовые регулярные выражения
REG_ICASE
Сопоставление regexec()
игнорирует регистр символов
REG_NEWLINE
Операторы, заменяющие любой символ, не включают символ конца строки
REG_NOSUB
Информация о начале и конце вложенною шаблона не требуется (см текст)
Флаги для сопоставления регулярных выражений с помощью
regexec()
приведены в табл. 12.8.
Таблица 12.8. Флаги дли
regexec()
Константа
Значение
REG_NOTBOL
Оператор ^ (начало строки) не сопоставляется
REG_NOTEOL
Оператор $ (конец строки) не сопоставляется
Флаги
REG_NEWLINE
, REG_NOTBOL
и REG_NOTEOL
взаимодействуют друг с другом. Это немного запутано, поэтому мы будем продвигаться небольшими шажками.
• Когда в
cflags
не включен REG_NEWLINE
, символ конца строки действует в качестве обычного символа. С ним может быть сопоставлен метасимвол '.
' (любой символ), а также дополненные списки символов ('[^...]
'). При этом $
не сопоставляется немедленно с началом вставленного символа новой строки, а ^
не сопоставляется немедленно с его концом.
• Когда в
eflags
установлен REG_NOTBOL
, оператор ^
не соответствует началу строки. Это полезно, когда параметр string
является адресом символа в середине сопоставляемого текста.
• Сходным образом, когда в
eflags
установлен REG_NOTEOL
, оператор $
не соответствует концу строки.
• Когда в
cflags
включен REG_NEWLINE
, то:
• Символ конца строки не соответствует '
.
' или дополненному списку символов.
• Оператор
^
всегда соответствует положению непосредственно за вставленным символом конца строки независимо от установки REG_BOL
.
• Оператор
$
всегда соответствует положению непосредственно перед вставленным символом конца строки независимо от установки REG_EOL
.
Когда вы осуществляете построчный ввод/вывод, как в случае с
grep
, можно не включать REG_NEWLINE
в cflags
. Если в буфере несколько строк, и каждую из них нужно рассматривать как отдельную, с сопоставлением ^
и $
, тогда следует включить REG_NEWLINE
.
Структура
regex_t
по большей части непрозрачна. Код уровня пользователя может исследовать лишь один член этой структуры; остальное предназначено для внутреннего использования процедурами регулярных выражений:
typedef struct {
/* ...здесь внутренний материал... */
size_t re_nsub;
/* ...здесь внутренний материал... */
} regex_t;
В структуре
regmatch_t
есть по крайней мере два члена для использования кодом уровня пользователя:
typedef struct {
/* ...здесь возможный внутренний материал... */
regoff_t rm_so; /* Смещение начала вложенной строки в байтах */
regoff_t rm_eo; /* Смещение первого байта после вложенной строки */
/* ...здесь возможный внутренний материал... */
} regmatch_t;
Как поле
re_nsub
, так и структура regmatch_t
предназначены для сопоставления вложенных выражений. Рассмотрим такое регулярное выражение:
[:пробел:]]+([[:цифра:]]+)[[:пробел:]]+([[:буква:]])+
Каждое из двух вложенных выражений в скобках могут соответствовать одному или более символам. Более того, текст, соответствующий каждому вложенному выражению, может начинаться и заканчиваться в произвольных участках строки.
regcomp()
устанавливает в поле re_nsub
число вложенных выражений в скобках внутри регулярного выражения, regexec()
заполняет массив pmatch
структур regmatch_t
смещениями начальных и конечных байтов текста, соответствующих этим вложенным выражениям. Вместе эти данные позволяют заменять текст — удалять его или заменять другим текстом, точно так же, как в текстовом редакторе
pmatch[0]
описывает часть строки, соответствующую всему регулярному выражению. Участок от pmatch[1]
до pmatch[preg->re_nsub]
описывает ту часть, которая соответствует каждому вложенному выражению в скобках. (Таким образом, вложенные выражения нумеруются начиная с 1.) Элементы rm_so
и rm_eo
не используемых элементов массива pmatch
установлены в -1.
regexec()
заполняет не более nmatch-1
элементов pmatch
; поэтому следует убедиться, что имеется по крайней мере на 1 элемент больше, чем в preg->re_nsub
.
Наконец, флаг
REG_NOSUB
для regcomp()
означает, что начальная и завершающая информация не нужна. Этот флаг следует использовать, когда эти сведения не нужны; это потенциально может довольно значительно повысить производительность regexec()
.
Другими словами, если все, что вам нужно знать, это «соответствует ли?», включите
REG_NOSUB
. Однако, если нужно также знать, «где находится соответствующий текст?», этот флаг следует опустить.
В заключение, как
regcomp()
, так и regexec()
возвращают 0, если они успешны, или определенный код ошибки, если нет. Коды ошибок перечислены в табл. 12.9.
Таблица 12.9. Коды ошибок
regcomp()
и regexec()
Константа
Значение
REG_BADBR
Содержимое '\{...\}
' недействительно.
REG_BADPAT
Регулярное выражение недействительно
REG_BADRPT
Символу ?
, +
или *
не предшествует действительное регулярное выражение.
REG_EBRACE
Фигурные скобки ('\{...\}
') не сбалансированы
REG_EBRACK
Квадратные скобки ('[...]
') не сбалансированы
REG_ECOLLATE
В шаблоне использован недействительный элемент сортировки
REG_ECTYPE
В шаблоне использован недействительный класс символов
REG_EESCAPE
В шаблоне есть завершающий символ \
REG_EPAREN
Группирующие скобки ('(...)
' или '\(...\)
') не сбалансированы
REG_ERANGE
Конечная точка в диапазоне не действительна
REG_ESPACE
Функции не хватило памяти
REG_ESUBREG
Цифра в '\цифра
' недействительна
REG_NOMATCH
Строка не соответствует шаблону
Для демонстрации регулярных выражений
ch12-grep.c
предусматривает базовую реализацию стандартной программы grep
, которая отыскивает соответствие шаблону. Наша версия использует по умолчанию базовые регулярные выражения. Для использования вместо этого расширенных регулярных выражений она принимает опцию -E
, а для игнорирования регистра символов опцию -i
. Как и настоящая grep
, если в командной строке не указаны файлы, наша grep
читает со стандартного ввода, а для обозначения стандартного ввода, как и в настоящей grep
, может быть использовано имя файла '-
'. (Эта методика полезна для поиска в стандартном вводе наряду с другими файлами.) Вот программа:
1 /* ch12-grep.c - Простая версия grep, использующая функции POSIX */
2
3 #define _GNU_SOURCE 1 /* для getline)) */
4 #include
5 #include
6 #include
7 #include
8 #include
9
10 char *myname; /* для сообщений об ошибках */
11 int ignore_case = 0; /* опция -i: игнорировать регистр */
12 int extended = 0; /* опция -E: использовать расширенные регулярные выражения */
13 int errors = 0; /* число ошибок */
14
15 regex_t pattern; /* шаблон для поиска */
16
17 void compile_pattern(const char *pat);
18 void process(const char *name, FILE *fp);
19 void usage(void);
Строки 10–15 объявляют глобальные переменные программы. Первый набор (строки 10–13) для опций и сообщений об ошибках. Строка 15 объявляет
pattern
, в которой хранится откомпилированный шаблон. Строки 17–19 объявляют другие функции программы.
21 /* main --- обработка опций, открывание файлов */
22
23 int main(int argc, char **argv)
24 {
25 int с;
26 int i;
27 FILE *fp;
28
29 myname = argv[0];
30 while ((c = getopt(argc, argv, ":iE")) != -1) {
31 switch (c) {
32 case 'i':
33 ignore_case = 1;
34 break;
35 case 'E':
36 extended = 1;
37 break;
38 case '?':
39 usage();
40 break;
41 }
42 }
43
44 if (optind == argc) /* проверка исправности */
45 usage();
46
47 compile_pattern(argv[optind]); /* компилировать шаблон */
48 if (errors) /* ошибка компиляции */
49 return 1;
50 else
51 optind++;
В строке 29 устанавливается значение
myname
, а строки 30–45 анализируют опции. Строки 47–51 компилируют регулярное выражение, помещая результаты в pattern
, compilе_раttern()
увеличивает значение errors
, если была проблема. (Соединение функций посредством глобальной переменной, как здесь, обычно считается плохой манерой. Для небольших программ, подобным этой, это сойдет, но для более крупных программ такое сопряжение может стать проблемой.) Если не было ошибок, строка 51 увеличивает значение optind
так, что оставшиеся аргументы представляют файлы для обработки.
53 if (optind == argc) /* файлов нет, по умолчанию stdin */
54 process("standard input", stdin);
55 else {
56 /* цикл с файлами */
57 for (i = optind; i < argc; i++) {
58 if (strcmp(argv[i], "-") == 0)
59 process("standard input", stdin);
60 else if ((fp = fopen(argv[i], "r")) != NULL) {
61 process(argv[i], fp);
62 fclose(fp);
63 } else {
64 fprintf(stderr, "%s: %s: could not open: %s\n",
65 argv[0], argv[i], strerror(errno));
66 errors++;
67 }
68 }
69 }
70
71 regfree(&pattern);
72 return errors != 0;
73 }
Строки 53–69 обрабатывают файлы, отыскивая соответствующие шаблону строки. Строки 53–54 обрабатывают случай, когда файлы не указаны: программа читает со стандартного ввода. В противном случае, строки 57–68 обрабатывают в цикле файлы. Строка 58 обрабатывает особый случай '
-
', обозначающий стандартный ввод, строки 60–62 обрабатывают обычные файлы, а строки 63–67 обрабатывают ошибки.
75 /* compile_pattern --- компиляция шаблона */
76
77 void compile_pattern(const char *pat)
78 {
79 int flags = REG_NOSUB; /* информация о месте совпадения не требуется */
80 int ret;
81 #define MSGBUFSIZE 512 /* произвольно */
82 char error[MSGBUFSIZE];
83
84 if (ignore_case)
85 flags |= REG_ICASE;
86 if (extended)
87 flags |= REG_EXTENDED;
88
89 ret = regcomp(&pattern, pat, flags);
90 if (ret != 0) {
91 (void)regerror(ret, &pattern, error, sizeof error);
92 fprintf(stderr, "%s: pattern '%s': %s\n", myname, pat, error);
93 errors++;
94 }
95 }
Строки 75–95 определяют функцию
compile_pattern()
. Она сначала устанавливает REG_NOSUB
в flags
, поскольку нам нужно знать лишь «подходит ли строка?», а не «где в строке располагается подходящий текст?»
Строки 84-85 добавляют дополнительные флаги в соответствии с опциями командной строки. Строка 89 компилирует шаблон, а строки 90–94 сообщают о возникших ошибках
97 /* process --- читает строки текста и сопоставляет их с шаблоном */
98
99 void process(const char *name, FILE *fp)
100 {
101 char *buf = NULL;
102 size_t size = 0;
103 char error[MSGBUFSIZE];
104 int ret;
105
106 while (getline(&buf, &size, fp) != -1) {
107 ret = regexec(&pattern, buf, 0, NULL, 0);
108 if (ret != 0) {
109 if (ret != REG_NOMATCH) {
110 (void)regerror(ret, &pattern, error, sizeof error);
111 fprintf(stderr, "%s: file %s: %s\n", myname, name, error);
112 free(buf);
113 errors++;
114 return;
115 }
116 } else
117 printf("%s: %s", name, buf); /* вывести подходящие строки */
118 }
119 free(buf);
120 }
Строки 97–120 определяют функцию
process()
, которая читает файл и выполняет сопоставление с регулярным выражением. Внешний цикл (строки 106–119) читает строки ввода. Для избежания проблем с длиной строки мы используем getline()
(см. раздел 3.2.1.9 «Только GLIBC: чтение целых строк: getline()
и getdelim()
»). Строка 107 вызывает regexec()
. Ненулевое возвращаемое значение означает либо неудачное сопоставление, либо какую-нибудь другую ошибку. Строки 109–115 соответственно проверяют REG_NOMATCН
и выводят ошибку лишь тогда, когда возникла какая-нибудь другая проблема — неудачное сопоставление не является ошибкой
Если возвращаемое значение равно 0, строка совпала с шаблоном и соответственно строка 117 выводит имя файла и совпавшую строку.
122 /* usage --- вывод сообщения об использовании и выход */
123
124 void usage(void)
125 {
126 fprintf(stderr, "usage: %s [-i] [-E] pattern [ files ... ]\n", myname);
127 exit(1);
128 }
Функция
usage()
выводит сообщение об использовании и завершает программу. Она вызывается, когда предоставлены недействительные аргументы или не предоставлен шаблон (строки 38–40 и 44–45).
Вот и все! Скромная, но тем не менее полезная версия
grep
в 130 строк кода.
12.9. Рекомендуемая литература
1. Programming Pearls, 2nd edition, by Jon Louis Bentley Addison-Wesley, Reading, Massachusetts, USA, 2000. ISBN- 0-201-65788-0. См. также веб-сайт этой книги.[131]
Проектирование программы с операторами проверки является одной из главных тем в этой книге.
2. Building Secure Software How to Avoid Security Problems the Right Way, by John Viega and Gary McGraw Addison-Wesley, Reading, Massachusetts, USA, 2001. ISBN: 0-201-72152-X.
Состояния гонки являются одной из многих проблем, о которых нужно побеспокоиться при написании безопасного программного обеспечения. Другой проблемой являются случайные числа. Данная книга рассматривает наряду с другими обе эти проблемы (Мы упоминали о ней в предыдущей главе.)
3. The Art of Computer Programming. Volume 2. Seminumerical Algorithms, 3rd edition, by Donald E. Knuth Addison-Wesley, Reading, Massachusetts, USA, 1998. ISBN- 0-201-89684-2.[132] См также веб-сайт этой книги.[133]
Это классическое справочное руководство по генерации случайных чисел.
4. Random Number Generation and Monte Carlo Methods, 2nd edition, by James E. Gentle Springer-Verlag, Berlin, Germany. 2003. ISBN: 0-387-00178-6.
Данная книга широко освещает методы генерации и тестирования псевдослучайных чисел. Хотя для неё также требуется математическая и статистическая подготовка, уровень не такой высокий, как в книге Кнута. (Благодарим Nelson H.F. Beebe за указание этой ссылки.)
5. sed & awk, 2nd edition, by Dale Dougherty and Arnold Robbins. O'Reilly and Associates, Sebastopol, California, USA, 1997. ISBN: 1-56592-225-5.
Эта книга осторожно вводит в регулярные выражения и обработку текста, начиная с
grep
и продвигаясь к более мощным инструментам sed
и awk
.
6. Mastering Regular Expressions, 2nd edition, by Jeffrey E.F. Friedl. O'Reilly and Associates, Sebastopol, California, USA, 2002.[134] ISBN: 0-59600-289-0.
Регулярные выражения являются важной частью Unix. Чтобы научиться заменять, вырезать и распределять текст с использованием регулярных выражений, мы рекомендуем эту книгу
7. Руководство для GNU
grep
также объясняет регулярные выражения. На системе GNU/Linux для просмотра локальной копии вы можете использовать 'info grep
'. Или использовать браузер для прочтения онлайн-документации проекта GNU для grep
.[135]
12.10. Резюме
• Операторы проверки предоставляют способ сделать утверждения о предполагаемом состоянии программы. Они являются полезным инструментом для проектирования и отладки и обычно должны оставаться в коде изделия. Однако, будьте внимательны, чтобы не перепутать операторы проверки с проверками возможных ошибок времени исполнения.
• Функции
memXXX()
являются аналогичными более известным функциям strXXX()
. Самой большой их ценностью является то. что они могут работать с двоичными данными; нулевые байты не отличаются от других байтов. Больше известна memcpy()
против memmove()
, обрабатывающей перекрывающиеся копии.
• Временные файлы полезны во многих приложениях. Функции API
tmpfile()
и mkstemp()
являются предпочтительными способами создания временных файлов, в то же время позволяя избежать состояния гонки и связанных с ней проблем безопасности. Многие программы для указания местоположения своих временных файлов используют переменную окружения TMPDIR
, а если она не определена, приемлемое значение по умолчанию (обычно /tmp
). Это хорошее соглашение, которое следует принять на вооружение в своих программах.
• Функция
abort()
посылает вызывающему процессу сигнал SIGABRT
. Результатом является завершение процесса и создание дампа ядра, предположительно для отладки.
•
setjmp()
и longjmp()
обеспечивают нелокальный переход. Это мощная возможность, которая должна использоваться с осторожностью. sigsetjmp()
и siglongjmp()
сохраняют и восстанавливают маску сигналов процесса, когда программа осуществляет нелокальный переход. Проблемы с нелокальными переходами иногда перевешивают их преимущества, соответственно используйте эти процедуры лишь когда нет лучшего способа структурировать ваше приложение.
• Случайные числа полезны для множества приложений. Большинство программ используют псевдослучайные числа — последовательности номеров, которые кажутся случайными, но которые могут быть воспроизведены с помощью одного и того же начального значения.
rand()
и srand()
являются первоначальными функциями API, стандартизованными языком С. На многих системах rand()
использует низкокачественный алгоритм, random()
и srandom()
используют лучший алгоритм, включены в стандарт POSIX и являются предпочтительными по сравнению с rand()
и srand()
. Используйте специальные файлы /dev/random
и /dev/urandom
, если (а) они доступны и (б) если вам нужны случайные числа высокого качества.
• Три функции API предоставляют все более мощные возможности для развертывания метасимволов (подстановки символов).
•
fnmatch()
является простейшей, возвращающей true/false, если данная строка соответствует или не соответствует шаблону символов подстановки оболочки.
•
glob()
просматривает файловую систему, возвращая список путей, которые соответствуют данному шаблону. Когда требуются стандартные возможности glob()
, следует использовать эту функцию. Хотя GLIBC версия glob()
имеет некоторые расширения, переносимые программы, которым нужны дополнительные возможности, должны вместо этого использовать wordexp()
. (Программы, которые будут работать лишь на системах GNU/Linux, не должны стесняться использовать полную мощь GLIBC glob()
.)
•
wordexp()
не только делает то, что делает glob()
, но также выполняет полное развертывание слов в стиле оболочки, включая развертывание тильды, развертывание переменных оболочки и подстановку команд.
• Функции
regcomp()
и regexec()
обеспечивают доступ к базовым и расширенным регулярным выражениям POSIX. Используя одну из этих функций, можно заставить свою программу вести себя идентично со стандартными утилитами, значительно упрощая использование программы пользователями, знакомыми с GNU/Linux и Unix.
Упражнения
1. Используйте
read()
и memcmp()
для написания простой версии программы cmp
, которая сравнивает два файла. Вашей версии не нужно поддерживать какие-нибудь опции.
2. Используйте макрос
getc()
и прямое сравнение каждого прочитанного символа для написания другой версии cmp
, которая сравнивает два файла. Сравните производительность этой версии с производительностью написанной в предыдущем упражнении.
3. (Средней трудности) Рассмотрите функции
fgets()
и GLIBC getline()
. Полезна ли memcpy()
для их реализации? Набросайте с ее использованием возможную реализацию fgets()
.
4. (Трудное) Найдите исходный код GLIBC версии
memcmp()
. Он должен быть на одном из CD-ROM с исходным кодом в вашем дистрибутиве GNU/Linux, или же вы можете найти его в сети. Исследуйте код и объясните его.
5. Проверьте свою память. Как
tmpfile()
организует удаление файла, когда закрыт указатель файла?
6. Используя
mkstemp()
и fdopen()
, а также другие необходимые функции или системные вызовы, напишите свою версию tmpfile()
. Протестируйте ее тоже.
7. Опишите преимущества и недостатки использования
unlink()
для имени файла, созданного mkstemp()
, непосредственно после возвращения mkstemp()
.
8. Напишите свою версию
mkstemp()
, используя mktemp()
и open()
. Как вы можете обеспечить те же гарантии уникальности, которые обеспечивает mkstemp()
?
9. Программы, использующие
mkstemp()
, должны обеспечивать удаление файла при завершении. (Предположим, что файл не удаляется сразу же после открытия по тем или иным причинам.) Это включает в себя случай, когда может поступить сигнал завершения. Поэтому удаление файла должно быть частью перехватчика сигнала. Как вы это сделаете?
10. (Трудное) Даже с урезанной очисткой при обработке сигнала все еще имеется состояние гонки. Есть небольшое окно между созданием временного файла функцией
mkstemp()
и возвращением и записью его имени в переменной (для использования функцией обработки сигнала). Если в это окно попадает не перехваченный сигнал, программа завершается и оставляет временный файл. Как вы закроете это окно? (Спасибо Jim Meyering.)
11. Попробуйте откомпилировать и запустить
ch12-setjmp.c
на как можно большем количестве различных систем с использованием как можно большего количества различных компиляторов, к каким у вас есть доступ. Попробуйте компилировать с различными уровнями оптимизации. Какие изменения поведения вы видели (если они были)?
12. Посмотрите файл
/usr/src/libc/gen/sleep.c
в дистрибутиве исходного кода V7 Unix. Он содержит реализацию функции sleep()
, описанную в разделе 10.8.1 «Сигнальные часы: sleep()
, alarm()
и SIGALARM
». Распечатайте ее и прокомментируйте в стиле наших примеров, чтобы объяснить ее работу.
13. Посмотрите справочную страницу lrand48(3) на системе GNU/Linux или System V. Выглядит ли этот интерфейс более простым или трудным для использования, чем
random()
?
14. Возьмите
ch08-nftw.c
из раздела 8.4.3 «Перемещение по иерархии: nftw()
» и добавьте опцию --exclude=pattern
. Файлы, соответствующие паттерну, не должны выводиться.
15. (Трудное) Почему GLIBC нужны указатели на альтернативные версии функций стандартных каталогов и
stat()
? Не может ли она вызывать их непосредственно?
16. Измените
ch12-glob.c
для использования функции wordexp()
. Поэкспериментируйте с ней, проделав несколько дополнительных вещей, которые она предоставляет. Не забудьте взять аргументы командной строки в кавычки, чтобы wordexp()
на самом деле выполнила свою работу!
17. Стандартная
grep
выводит имя файла, лишь когда в командной строке указано больше одного файла. Сделайте так, чтобы ch12-grep.c
действовала таким же образом.
18. Посмотрите справочную страницу grep(1). Добавьте к
ch12-grep.c
стандартные опции -e
, -s
и -v
.
19. Напишите простую замещающую программу:
subst [-g] шаблон подстановка [файлы ...]
Она должна читать текстовые строки из указанных файлов или из стандартного ввода, если они не указаны. Каждая строка должна сравниваться на соответствие шаблону. Если обнаружено соответствие, оно должно замещаться подстановкой.
Если указана опция
-g
, замещаться должно не только первое совпадение, но и все остальные совпадения в строке.
В главе 6, «Общие библиотечные интерфейсы — часть 1», был представлен первый набор API библиотеки общего пользования. В некотором смысле, эти API поддерживают работу с фундаментальными объектами, которыми управляют системы Linux и Unix: время дня, пользователи и группы для файлов, сортировка и поиск.
Данная глава более эклектична; функции API, рассмотренные здесь, не особо связаны друг с другом. Однако, все они полезны в повседневном программировании под Linux/Unix. Наше представление движется от простых, более общих функций API к более сложным и более специализированным.
12.1. Операторы проверки: assert()
assert()Оператор проверки (assertion) является утверждением, которое вы делаете о состоянии своей программы в определенный момент времени ее исполнения. Использование операторов проверок для программирования было первоначально разработано Хоаром (C.A.R. Hoare)[121]. Общая идея является частью «верификации программы»: так же, как вы проектируете и разрабатываете программу, вы можете показать, что она правильна, делая тщательно аргументированные утверждения о проявлениях кода вашей программы. Часто такие утверждения делаются об инвариантах — фактах о состоянии программы, которые, как предполагается, остаются верными на протяжении исполнения куска программы.
Операторы проверки особенно полезны для описания двух разновидностей инвариантов: предусловий и постусловий: условий, которые должны быть истинными соответственно перед и после исполнения сегмента кода. Простым примером предусловий и постусловий является линейный поиск:
/* lsearch --- возвратить индекс с данным значением в массиве или -1, если не найдено */int lsearch(int *array, size_t size, int value) { size_t i; /* предусловие: array != NULL */ /* предусловие: size > 0 */ for (i = 0; i < size; i++) if (array[i] == value) return i; /* постусловие: i == size */ return -1;}Этот пример определяет условия, используя комментарии. Но не было бы лучше проверить условия с использованием кода? Это является задачей макроса
assert()#include /* ISO С */ void assert(/* скалярное выражение */);Когда скалярное выражение ложно, макрос
assert()abort()abort()ch12-assert.clsearch()main()1 /* ch12-assert.с --- демонстрация операторов проверки */23 #include 4 #include 56 /* lsearch --- возвращает индекс с данным значением в массиве или -1, если не найдено */78 int lsearch(int *array, size_t size, int value)9 {10 size_t i;1112 assert(array != NULL);13 assert(size > 0);14 for (i = 0; i < size; i++)15 if (array[i] == value)16 return i;1718 assert(i == size);1920 return -1;21 }2223 /* main --- проверить наши условия */2425 int main(void)26 {27 #define NELEMS 428 static int array[NELEMS] = { 1, 17, 42, 91 };29 int index;3031 index = lsearch(array, NELEMS, 21);32 assert(index == -1);3334 index = lsearch(array, NELEMS, 17);35 assert(index == 1);3637 index = lsearch(NULL, NELEMS, 10); /* won't return */3839 printf("index = %d\n", index);4041 return 0;42 }После компиляции и запуска оператор проверки в строке 12 «выстреливает»:
$ ch12-assert /* Запуск программы */ch12-assert: ch12-assert.c:12: lsearch: Assertion 'array != ((void *)0)' failed.Aborted (core dumped)Сообщение от
assert()NULL((void*)0)'Сообщение '
Aborted (core dumped)ch12-assertcorecoreassert()Вы можете отменить оператор проверки, компилируя свою программу с помощью опции командной строки '
-DNDEBUGassert()$ gcc -DNDEBUG=1 ch12-assert.c -о ch12-assert /* Компиляция с -DNDEBUG */$ ch12-assert /* Запуск */Segmentation fault (core dumped) /* Что случилось? */Здесь мы получили настоящий дамп ядра! Мы знаем, что операторы проверки были запрещены; сообщения «failed assertion» нет. Что же случилось? Рассмотрите строку 15
lsearch()main()arrayNULLNULLNULLSIGSEGVЭтот случай поднимает важный момент относительно операторов проверки. Часто программисты ошибочно используют операторы проверки вместо проверки ошибок времени исполнения. В нашем случае тест '
array != NULLif (array == NULL) return -1;Тест '
size > 0sizelsearch()size <= 0Логика, стоящая за отменой оператора проверки, заключается в том, что дополнительные проверки могут снизить производительность программы и поэтому должны быть запрещены в заключительной версии программы. Хоар[123], однако, сделал такое замечание:
«В конце концов, абсурдно делать тщательные проверки безопасности при отладочных запусках, когда к результатам нет никакого доверия, а затем удалять их из финальных версий, когда ошибочный результат может быть дорогим или катастрофическим. Что бы мы подумали об энтузиасте-мореплавателе, который надевает свой спасательный жилет при тренировке на сухой земле и снимает его, как только выходит в море?»
С такими мнениями, наша рекомендация заключается во внимательном использовании операторов проверки- во-первых, для любого данного оператора проверки рассмотрите возможность использования вместо него проверки времени исполнения. Во-вторых, тщательно разместите свой оператор проверки, чтобы не было возражений против их оставления на своем месте лаже в финальной версии вашей программы.
Наконец, отметим следующее из раздела «Ошибки» справочной страницы GNU/Linux assert(3):
assert()NDEBUGЗнаменитый принцип неопределенности Гейзенберга из физики указывает, что чем более точно вы определите скорость частицы, тем менее точно вы определите ее положение, и наоборот. В терминах непрофессионала это означает что простой факт наблюдения частицы влияет на нее.
Сходное явление совершается в программировании, не связанном с физикой частиц: действие компилирования программы для отладки или запуска ее а режиме отладки может изменить поведение программы. В частности, первоначальная ошибка может исчезнуть. Такие ошибки в разговоре называют гейзенберговскими.
Справочная страница предостерегает нас от использования при вызовах
assert()assert(*p++ == '\n');Здесь побочным эффектом является увеличение указателя p как часть теста. Когда определен
NDEBUG
12.2. Низкоуровневая память: функции memXXX()
memXXX()Несколько функций предоставляют возможность для работы с произвольными блоками памяти низкоуровневые службы. Все их имена начинаются с префикса '
mem#include /* ISO C */ void *memset(void *buf, int val, size_t count);void *memcpy(void *dest, const void *src, size_t count);void *memmove(void *dest, const void *src, size_t count);void *memccpy(void *dest, const void *src, int val, size_t count);int memcmp(const void *buf1, const void *buf2, size_t count);void *memchr(const void *buf, int val, size_t count);
12.2.1. Заполнение памяти: memset()
memset()Функция
memset()unsigned charcountbufvoid *p = malloc(count);if (p != NULL) memset(p, 0, count);Однако
memset()buf
12.2.2. Копирование памяти: memcpy()
, memmove()
и memccpy()
memcpy()memmove()memccpy()Три функции копируют один блок памяти в другой. Первые две функции отличаются в обработке перекрывающихся областей памяти; третья копирует память, но останавливается при встрече с определенным значением.
void *memcpy(void *dest, const void *src, size_t count)Это простейшая функция. Она копирует
countsrcdestdestvoid *memmove(void *dest, const void *src, size_t count)Подобно
memcpy()countsrcdestdestvoid *memccpy(void *dest, const void *src, int val, size_t count)Эта копирует байты из
srcdestvaldestcountvaldestvalNULLТеперь, в чем проблема с перекрывающейся памятью? Рассмотрим рис. 12.1.
Рис. 12.1. Перекрывающиеся копии
Целью является скопировать четыре экземпляра
struct xyzdata[0]data[3]data[3]data[6]data[3]data[0]data[3]data[6]Функция
memcpy()memmove()memcpy()memmove()Какую из них использовать в своем коде? Для библиотечной функции, которая не знает, какие области памяти ей передаются, следует использовать
memmove()memcpy()Как для
memcpy()memmove()strcpy()dest = src;(Справочные страницы во многих системах не помогают, предлагая прототип в виде '
void *memcpy(void *buf1, void *buf2, size_t n)
12.2.3. Сравнение блоков памяти: memcmp()
memcmp()Функция
memcmp()countstrcmp()Вы можете поинтересоваться: «Почему бы не использовать для такого сравнения
strcmp()memcmp()\0memcmp()Другим преимуществом
memcmp()/* memcmp --- пример реализации на С, НЕ для реального использования */int memcmp(const void *buf1, const void *buf2, size_t count) { const unsigned char *cp1 = (const unsigned char*)buf1; const unsigned char *cp2 = (const unsigned char*)buf2; int diff; while (count-- != 0) { diff = *cp1++ - *cp2++; if (diff != 0) return diff; } return 0;}Скорость может быть достигнута в результате использования специальных инструкций «блочного сравнения памяти», которые поддерживают многие архитектуры, или в результате сравнения единиц, превышающих байты. (Эта последняя операция коварна, и лучше оставить ее автору библиотеки.)
По этим причинам всегда следует использовать вашу библиотечную версию
memcmp()
12.2.4. Поиск байта с данным значением: memchr()
memchr()Функция
memchr()strchr()memcmp()strcmp()memchr()GNU
wcmemchr()wсwc.c257 else if (!count_chars && !count_complicated)258 {259 /* Использует отдельный цикл при подсчете лишь строк или строк и байтов -260 но не символов или слов. */261 while ((bytes_read = safe_read(fd, buf, BUFFER_SIZE)) > 0)262 {263 register char *p = buf;264265 if (bytes_read == SAFE_READ_ERROR)266 {267 error(0, errno, "%s", file);268 exit_status = 1;269 break;270 }271272 while ((p = memchr(p, '\n', (buf + bytes_read) - p)))273 {274 ++p;275 ++lines;276 }277 bytes += bytes_read;278 }279 }Внешний цикл (строки 261–278) читает блоки данных из входного файла. Внутренний цикл (строки 272–276) использует
memchr()(buf + bytes_read) - рКомментарии в строках 259–260 нуждаются в некотором объяснении. Вкратце, современные системы могут использовать символы, занимающие более одного байта в памяти и на диске. (Это несколько более подробно обсуждается в разделе 13.4 «Не могли бы вы произнести это для меня по буквам?».) Таким образом,
wc12.3. Временные файлы
Временный файл является в точности тем, что звучит в его названии: файл, в котором при исполнении программы хранятся данные, которые больше не нужны после завершения программы.
sort-sortвсеsortsortУдивительно, но имеются пять различных функций для создания временных файлов. Три из них работают посредством создания строк, представляющих (предположительно) уникальные имена файлов. Как мы увидим, их обычней следует избегать. Оставшиеся две работают путем создания и открытия временного файла; эти функции предпочтительнее для использования.
12.3.1. Создание временных имен файлов (плохо)
Имеются три функции, назначением которых является создание имени уникального, не существующего файла. Получив такое имя, вы можете использовать его для создания временного файла. Поскольку имя уникально, вам «гарантируется» исключительное использование файла. Вот объявления функций:
#include char *tmpnam(char *s); /* ISO С */char *tempnam(const char *dir, const char *pfx); /* XSI */char *mktemp(char *template); /* ISO С */Все эти функции предусматривают различные вариации одной и той же темы они заполняют или создают буфер с путем уникального временного имени файла. Файл уникален в том, что создаваемое имя не существует во время создания и возвращения его функциями. Функции работают следующим образом:
char *tmpnam(char *s)Генерирует уникальное имя файла. Если
sNULLL_tmpnamsNULLP_tmpdirP_tmpdirL_tmpnamchar *tempnam(const char *dir, const char *pfx)Подобно
tmpnam()dirNULLP_tmpdirpfxNULLtempnam()free()char *mktemp(char *template)Генерирует уникальные имена файлов на основе шаблона. Последними шестью символами
templateХХХХХХЗАМЕЧАНИЕ. Аргумент
templatemktemp()/* Код в старом стиле: не используйте его */char *tfile = mktemp("/tmp/myprogXXXXXX");/* ...использование файла... */На современных системах такой код. вероятно, завершится неудачей, в наши дни строковые константы находятся в сегментах памяти только для чтения.
Использование этих функций довольно просто. Файл
ch12-mktemp.cmktemp()1 /* ch12-mktemp.с --- демонстрирует простое использование mktemp().2 Для краткости проверка ошибок опущена */34 #include 5 #include /* для флагов открытия */ 6 #include /* для PATH_MAX */ 78 int main(void)9 {10 static char template[] = "/tmp/myfileXXXXXX";11 char fname[PATH_MAX];12 static char mesg[] =13 "Here's lookin' at you, kid'\n"; /* вместо "hello, world" */14 int fd;1516 strcpy(fname, template);17 mktemp(fname);1819 /* ОКНО СОСТОЯНИЯ ГОНКИ ОТКРЫВАЕТСЯ */2021 printf("Filename is %s\n", fname);2223 /* ОКНО СОСТОЯНИЯ ГОНКИ ТЯНЕТСЯ ДОСЮДА */2425 fd = open(fname, O_CREAT|O_RDWR|O_TRUNC, 0600);26 write(fd, mesg, strlen(mesg));27 close(fd);2829 /* unlink(fname); */3031 return 0;32 }Переменная
templateХХХХХХfnamemktemp()Строка 25 открывает файл, создавая его при необходимости. Строка 26 записывает сообщение в
mesg$ ch12-mktemp /* Запуск программы */Filename is /tmp/myfileQES4WA /* Вывод имени файла */$ cat /tmp/myfileQES4WAHere's lookin' at you, kid' /* Содержит то, что ожидалось */$ ls -l /tmp/myfileQES4WA /* To же с владельцем и доступом */-rw------- 1 arnold devel 28 Sep 18 09:27 /tmp/myfileQES4WA$ rm /tmp/myfileQES4WA /* Удалить его */$ ch12-mktemp / * Используется ли повторно то же имя? */Filename is /tmp/myfileic7xCy /* Нет. Это хорошо */$ cat /tmp/myfileic7xCy /* Снова проверить содержание */Here's lookin' at you, kid!$ ls -l /tmp/myfileic7xCy /* Снова проверить владельца и доступ */-rw------- 1 arnold devel 28 Sep 18 09:28 /tmp/myfileic7xCyВсе кажется работающим замечательно,
mktemp()ch12-mktempИсторически
mktemp()ХХХХХХКак? Ну, Linux и Unix являются системами с квантованием времени, методикой, которая разделяет время процессора между всеми исполняющимися процессами. Это означает, что, хотя программа кажется выполняющейся все время, в действительности есть моменты, когда процессы спят, т.е. ожидают выполнения на процессоре.
Теперь рассмотрите программу профессора для отслеживания оценок студентов. Как профессор, так и злоумышленный студент в одно и то же время используют сильно нагруженную многопользовательскую систему. Программа профессора использует для создания временных файлов
mktemp()mktemp()Рис. 12.2. Состояние гонки с
mktemp()Вот что случилось.
1. Оценивающая программа использует
mktemp()mktemp()ch12-.mktemp.c2. Ядро останавливает оценивающую программу, чтобы могли поработать другие программы в системе. Это происходит до вызова
open()Пока оценивающая программа остановлена, студент создает файл с тем же самым именем, которое вернула
mktemp()3. Теперь оценивающая программа открывает файл и записывает в него данные. Студент создал файл с правами доступа
-rw-rw-rw-4. Когда оценивающая программа завершает работу, она удаляет временный файл. Однако, у студента все еще есть копия. Например, может быть возможность получения прибыли при заблаговременной продаже своим товарищам их оценок.
Наш пример упрощенный; помимо простого похищения данных с оценками умный (хотя и аморальный) студент мог бы вместо этого изменить данные. Если бы профессор не проверял результаты работы своей программы дважды, никто бы ничего не узнал.
ЗАМЕЧАНИЕ. Мы не рекомендуем делать что-либо из этого! Если вы студент, не пытайтесь сделать что-либо подобное. Первое и самое главное, это неэтично. Во-вторых, вас могут выгнать из школы. В-третьих, ваши профессора, наверное, не сталь наивны, чтобы использовать
mktemp()По приведенным и другим причинам, все три описанные в данном разделе функции не следует никогда использовать. Они существуют в POSIX и GLIBC лишь для поддержки старых программ, которые были написаны до того, как была осознана опасность этих процедур С этой целью системы GNU/Linux генерируют во время компоновки сообщение:
$ cc ch12-mktemp.c -о ch12-mktemp /* Компилировать программу *//tmp/cc1XCvD9.о(.text+0x35): In function 'main':: the use of 'mktemp' is dangerous, better use 'mkstemp'(Мы рассмотрим
mkstemp()Если бы в вашей системе не было
mkstemp()12.3.2. Создание и открывание временных файлов (хорошо)
Есть две функции, не имеющие проблем состояния гонки. Одна из них предназначена для использования с библиотекой
#include /* ISO С */ FILE *tmpfile(void);Другая функция для использования с системными вызовами на основе дескрипторов файлов:
#include /* XSI */ int mkstemp(char* template);tmpfile()FILE*w+bw+ch12-tmpfile.ctmpfile()/* ch12-tmpfile.с --- демонстрация tmpfile(). Проверка ошибок для краткости опущена */#include int main(void) { static char mesg[] = "Here's lookin' at you, kid!"; /* заменяет "hello, world" */ FILE *fp; char buf[BUFSIZ]; fp = tmpfile(); /* Получить временный файл */ fprintf(fp, "%s", mesg); /* Записать s него */ fflush(fp); /* Сбросить на диск */ rewind(fp); /* Перейти в начало */ fgets(buf, sizeof buf, fp); /* Прочесть содержимое */ printf("Got back <%s>\n", buf); /* Вывести полученные данные */ fclose(fp); /* Закрыть файл, закончить */ return 0; /* Все сделано */}Возвращенное значение
FILE*FILE*fopen()$ ch12-tmpfileGot back Ранее мы видели, что авторы GLIBC рекомендуют использование функции
mkstemp()$ cc ch12-mktemp.с -о ch12-mktemp /* Компилировать программу *//tmp/cc1XCvD9.о(.text+0x35): In function "main':: the use of 'mktemp' is dangerous, better use 'mkstemp'Эта функция похожа на
mktemp()ХХХХХХ-rw-------Более того, и это то, что делает
mkstemp()O_EXCLВозвращаемое значение является дескриптором открытого файла, который может использоваться для чтения и записи. Для удаления файла после завершения работы с ним должно использоваться имя пути, сохраненное теперь в переданном
mkstemp()ch12-mkstemp.cch12-tmpfile.с/* ch12-mkstemp.с --- демонстрирует mkstemp(). Проверка ошибок для краткости опущена */#include #include /* для флагов открытия */ #include /* для PATH_МАХ */ int main(void) { static char template[] = "/tmp/myfileXXXXXX"; char fname[PATH_MAX]; static char mesg[] = "Here's lookin' at you, kid!\n"; /* заменяет "hello, world" */ int fd; char buf[BUFSIZ]; int n; strcpy(fname, template); /* Копировать шаблон */ fd = mkstemp(fname); /* Создать и открыть временный файл */ printf("Filename is %s\n", fname); /* Вывести его для сведений */ write(fd, mesg, strlen(mesg)); /* Что-нибудь записать в файл */ lseek(fd, 0L, SEEK_SET); /* Перейти в начало */ n = read(fd, buf, sizeof(buf)); /* Снова прочесть данные; НЕ завышается '\0'! */ printf("Got back: %.*s", n, buf); /* Вывести его для проверки */ close(fd); /* Закрыть файл */ unlink(fname); /* Удалить его */ return 0;}При запуске получаем ожидавшиеся результаты:
$ ch12-mkstempFilename is /tmp/myfileuXFWINGot back: Here's lookin' at you, kid!
12.3.3. Использование переменной окружения TMPDIR
TMPDIRМногие стандартные утилиты обращают внимание на переменную окружения
TMPDIRTMPDIR/tmp/var/tmp/tmpМногие системы GNU/Linux предоставляют каталог
/dev/shmtmpfs:$ dfFilesystem 1K-blocks Used Available Use% Mounted on/dev/hda2 6198436 5136020 747544 88% //dev/hda5 61431520 27720248 30590648 48% /dnone 256616 0 256616 0% /dev/shmТип файловой системы
tmpfstmpfs/usr/share/dict/linux.words$ ls -l /tmp/randwords.big /* Показать размер */-rw-r--r-- 1 arnold devel 204652500 Sep 18 16:02 /tmp/randwords.big$ wc -l /tmp/randwords.big /* Сколько слов? */22713500 /tmp/randwords.big /* Свыше 22 миллионов! */Затем мы отсортировали файл, используя сначала каталог
/tmpTMPDIR/dev/shm$ time sort /tmp/randwords.big > /dev/null /* Использование реальных файлов */real 1m32.566suser 1m23.137ssys 0m1.740s$ time TMPDIR=/dev/shm sort /tmp/randwords.big > /dev/null /* Использование электронного диска */real 1m28.257suser 1m18.469ssys 0m1.602sИнтересно, использование электронного диска было лишь незначительно быстрее, чем использование обычных файлов. (В некоторых дальнейших тестах оно было даже в действительности медленнее!) Мы предполагаем, что в игру вступил буферный кэш ядра (см. раздел 4.6.2 «Создание файлов с помощью
creat()У электронного диска есть важный недостаток: он ограничен сконфигурированным для вашей системы размером пространства для подкачки.[127] Когда мы попытались отсортировать файл, содержащий 1000 копий файла с перемешанными словами, место на электронном диске закончилось, тогда как обычный sort завершился благополучно.
Использовать TMPDIR для своих программ просто. Мы предлагаем следующую схему.
const char template[] = "myprog.XXXXXX";char *tmpdir, *tfile;size_t count;int fd;if ((tmpdir = getenv("TMPDIR")) == NULL) /* Использовать значение TMPDIR, если имеется */ tmpdir = "/tmp"; /* В противном случае, /tmp по умолчанию */count = strlen(tmpdir) + strlen(template) + 2; /* Вычислить размер имени файла */tfile = (char *)malloc(count); /* Выделить для него память */if (tfile == NULL) /* Проверка ошибок */ /* восстановить */sprintf(tfile, "%s/%s", tmpdir, template); /* Создать завершающий шаблон */fd = mkstemp(tfile); /* Создать и открыть файл *//* ...использование tempfile через fd... */close(fd); /* Очистка */unlink(tfile);free(tfile);В зависимости от потребностей вашего приложения, вы можете захотеть немедленно удалить файл после его открытия, вместо его удаления как части завершающей очистки.
12.4. Совершение самоубийства: abort()
abort()Бывают моменты, когда программа просто не может продолжаться. Обычно лучше всего при этом выдать сообщение об ошибке и вызвать
exit()abort()#include /* ISO С */ void abort(void);Функция
abort()SIGABRTSIGABRTSIGABRTПримером
abort()assert()assert()abort()В соответствии со стандартом С, осуществляет
abort() FILE* 12.5. Нелокальные переходы
«Идите прямо в тюрьму. Не проходите GO. Не забирайте 200$».
Вы, без сомнения, знаете, чем является
gotogotogotoclean_upgotoОператор
gotogotoПочему полезен нелокальный переход? Рассмотрите интерактивную программу, которая считывает и выполняет программы. Предположим, пользователь запускает длительное задание, разочаровывается или меняет мнение о данном задании и нажимает CTRL-С для генерирования сигнала
SIGINT$ ed -p '> ' sayings /* Запуск ed, '> ' используется как приглашение */sayings: No such file or directory> a /* Добавить текст */Hello, worldDon't panic^C /* Сгенерировать SIGINT */? /* Сообщение об ошибке ''один размер подходит всем'' */> 1,$p /* ed возвращается в командную строку */Hello, world /* '1,$p' prints all the lines */Don't panic> w /* Сохранить файл */25> q /* Все сделано */Внутри себя
ed
12.5.1. Использование стандартных функций: setjmp()
и longjmp()
setjmp()longjmp()Нелокальные переходы осуществляются с помощью функций
setjmp()longjmp()#include /* ISO С */ int setjmp(jmp_buf env);void longjmp(jmp_buf env, int val);Тип
jmp_buftypedefsetjmp()envenvsetjmp()jmp_bufjmp_bufsetjmp()jmp_bufjmp_buf command_loop; /* На глобальном уровне *//* ... затем в main() ... */if (setjmp(command_loop) == 0) /* Состояние сохранено, продолжить */ ;else /* Мы попадаем сюда через нелокальный переход */ printf("?\n"); /* ed's famous message *//* ... теперь начать цикл команд ... */longjmp()jmp_bufsetjmp()setjmp()Стандарт С утверждает, что даже если
longjmp()setjmp()Возможность передать целое значение и вернуться обратно из
setjmp()gawkbreakcontinuewhiledo-whileforbreakcontinuesetjmp()eval.cgawk507 case Node_K_while:508 PUSH_BINDING(loop_tag_stack, loop_tag, loop_tag_valid);509510 stable_tree = tree;511 while (eval_condition(stable_tree->lnode)) {512 INCREMENT(stable_tree->exec_count);513 switch (setjmp(loop_tag)) {514 case 0: /* обычный не переход */515 (void)interpret(stable_tree->rnode);516 break;517 case TAG_CONTINUE: /* оператор continue */518 break;519 case TAG_BREAK: /* оператор break */520 RESTORE_BINDING(loop_tag_stack, loop_tag, loop_tag_valid);521 return 1;522 default:523 cant_happen();524 }525 }526 RESTORE_BINDING(loop_tag_stack, loop_tag, loop_tag_valid);527 break;Этот фрагмент кода представляет цикл
whilejmp_bufwhilewhileswitchsetjmp()setjmp()TAG_BREAKTAG_CONTINUEswitchОператор
breakawkTAG_BREAKlongjmp()continueawkTAG_CONTINUEeval.c657 case Node_K_break:658 INCREMENT(tree->exec_count); /* ... */675 longjmp(loop_tag, TAG_BREAK);676 break;677678 case Node_K_continue:679 INCREMENT(tree->exec_count); /* ... */696 longjmp(loop_tag, TAG_CONTINUE);670 break;Вы можете думать о
setjmp()longjmp()goto
12.5.2. Обработка масок сигналов: sigsetjmp()
и siglongjmp()
sigsetjmp()siglongjmp()По историческим причинам, которые, скорее всего, утомили бы вас до слез, стандарт С 1999 г. ничего не говорит о влиянии
setjmp()longjmp()Другими словами, если программа изменяет свою маску сигналов процесса между первым вызовом
setjmp()longjmp()longjmp()setjmp()Чтобы сделать обработку маски сигналов процесса явной, POSIX ввел две дополнительные функции и один
typedef#include /* POSIX */ int sigsetjmp(sigjmp_buf env, int savesigs); /* Обратите внимание: sigjmp_buf, не jmp_buf! */void siglongjmp(sigjmp_buf env, int val);Главным отличием является аргумент
savesigssigsetjmp()envsetjmp()siglongjmp()envsavesigsЗАМЕЧАНИЕ. POSIX также ясен в том, что если
savesigssetjmp()longjmp()sigsetjmp(env, 0)12.5.3. Важные предостережения
Есть несколько технических предостережений, о которых нужно знать.
Во-первых, поскольку сохранение и восстановление среды может быть беспорядочной машинно-зависимой задачей,
setjmp()longjmp()Во-вторых, стандарт С ограничивает использование
setjmp()• В качестве единственного контролирующего выражения в операторе цикла или условном операторе (
ifswitch• В качестве одного операнда выражения сравнения (
==<• В качестве операнда унарного оператора '
!• В качестве всего выражения оператора-выражения, возможно, приведенного к типу
void(void)setjmp(buf);В-третьих, если вы хотите изменить локальную переменную в функции, которая вызывает
setjmp()longjmp()volatilevolatilesetjmp()jmp_bufvolatile1 /* ch12-setjmp.с --- демонстрирует setjmp()/longjmp() и volatile. */23 #include 4 #include 56 jmp_buf env;78 /* comeback --- выполнение longjmp */910 void comeback(void)11 {12 longjmp(env, 1);13 printf("This line is never printed\n");14 }1516 /* main - вызов setjmp, действия с переменными, вывод значений */1718 int main(void)19 {20 int i = 5;21 volatile int j = 6;2223 if (setjmp(env) == 0) { /* первый раз */24 i++;25 j++;26 printf("first time: i = %d, j = %d\n", i, j);27 comeback));28 } else /* второй раз */29 printf("second time: i = %d, j = %d\n", i, j);3031 return 0;32 }В этом примере сохранение своего значения ко второму вызову
printf()лишьВ-четвертых, как описано в разделе 12.5.2 «Обработка масок сигналов:
sigsetjmp()siglongjmp()setjmp()longjmp()sigsetjmp()siglongjmp()В-пятых, эти процедуры содержат поразительные возможности для утечек памяти! Рассмотрим программу, в которой
main()setjmp()malloc()longjmp()main()ch12-memleak.c1 /* ch12-memleak.с --- демонстрирует утечки памяти с помощью setjmp()/longjmp(). */23 #include 4 #include /* для определения ptrdiff_t в GLIBC */ 5 #include 6 #include 78 jmp_buf env;910 void f1(void), f2(void);1112 /* main --- утечка памяти с помощью setjmp() и longjmp() */1314 int main(void)15 {16 char *start_break;17 char *current_break;18 ptrdiff_t diff;1920 start_break = sbrk((ptrdiff_t)0);2122 if (setjmp(env) == 0) /* первый раз */23 printf("setjmp called\n");2425 current_break = sbrk((ptrdiff_t) 0);2627 diff = current_break - start_break;28 printf("memsize = %ld\n", (long)diff);2930 f1();3132 return 0;33 }3435 /* f1 --- выделяет память, осуществляет вложенный вызов */3637 void f1(void)38 {39 char *p = malloc(1024);4041 f2();42 }4344 /* f2 --- выделяет память, выполняет longjmp */4546 void f2(void)47 {48 char *p = malloc(1024);4950 longjmp(env, 1);51 }Эта программа устанавливает бесконечный цикл, используя
setjmp()longjmp()sbrk()brk()sbrk()setjmp()longjmp()$ ch12-memleak /* Запуск программы */setjmp calledmemsize = 0memsize = 6372memsize = 6372memsize = 6372memsize = 10468memsize = 10468memsize = 14564memsize = 14564memsize = 18660memsize = 18660...Память утекает из программы, как через решето. Она работает до тех пор, пока не будет прервана от клавиатуры или пока не закончится память (в этом случае образуется основательный дамп ядра).
Каждая из функций
f1()f2()f2()longjmp()main()Этот код явно патологический, но он предназначен для иллюстрации нашей мысли:
setjmp()longjmp()f1()free()longjmp()ifТаким образом, при наличии
setjmp()longjmp()longjmp()setjmp()В-шестых,
longjmp()siglongjmp()atexit()В-седьмых,
setjmp()longjmp()При наличии всех этих проблем вы должны строго рассмотреть дизайн своей программы. Если вам не нужно использовать
setjmp()longjmp()12.6. Псевдослучайные числа
Многим приложениям нужны последовательности случайных чисел. Например, игровые программы, имитирующие бросание костей, раздачу карт или вращение барабанов игровой машины, нуждаются в возможности случайного выбора одного из возможных значений. (Подумайте о программе
fortuneЗАМЕЧАНИЕ. Природа случайности, генерация случайных чисел и их «качество» являются обширными темами, выходящими за рамки данной книги. Мы предоставляем введение в доступные функции API, но это все, что мы можем сделать Другие источники с более подробной информацией см в разделе 12.9 «Рекомендуемая литература»
Компьютеры по своему строению являются детерминистическими. Одно и то же вычисление с одними и теми же входными данными всегда должно давать одни и те же результаты. Соответственно, они не годятся для генерации истинно случайных чисел, то есть последовательностей чисел, в которых каждое число в последовательности полностью независимо от числа (или чисел), идущих перед ним. Вместо этого разновидности чисел, обычно используемых на программном уровне, называются псевдослучайными числами. То есть в любой данной последовательности номера выглядят независимыми друг от друга, но сама последовательность в целом повторяющаяся. (Эта повторяемость может быть ценным качеством; она обеспечивает детерминизм для программы в целом.)
Многие методы предоставления последовательностей псевдослучайных чисел работают посредством осуществления каждый раз одного и того же вычисления с начальным значением (seed). Сохраненное начальное значение затем обновляется для использования в следующий раз. API предоставляет способ указания нового начального значения. Каждое начальное значение дает одну и ту же последовательность псевдослучайных чисел, хотя различные начальные числа дают (должны давать) различные последовательности.
12.6.1. Стандартный С: rand()
и srand()
rand()srand()Стандартный С определяет две связанные функции для псевдослучайных чисел.
#include /* ISO С */ int rand(void);void srand(unsigned int seed);rand()RAND_MAXRAND_MAXsrand()seedsrand()rand()Следующая программа,
ch12-rand.crand()1 /* ch12-rand.c --- генерирует игральные кости, используя rand(). */23 #include 4 #include 56 char *die_faces[] = { /* Управляет ASCII графика! */7 " ",8 " * ", /* 1 */9 " ",1011 " ",12 " * * ", /* 2 */13 " ",1415 " ",16 " * * * ", /* 3 */17 " ",1819 " * * ",20 " ", /* 4 */21 " * * ",2223 " * * ",24 " * ", /* 5 */25 " * * ",2627 " * * * ",28 " ", /* 6 */29 " * * * ",30 };3132 /* main --- выводит N различных граней костей */3334 int main(int argc, char **argv)35 {36 int nfaces;37 int i, j, k;3839 if (argc !=2) {40 fprintf(stderr, "usage: %s number-die-faces\n", argv[0]);41 exit(1);42 }4344 nfaces = atoi(argv[1]);4546 if (nfaces <= 0) {47 fprintf(stderr, "usage: %s number-die-faces\n", argv[0]);48 fprintf(stderr, "\tUse a positive number!\n");49 exit(1);50 }5152 for (i = 1; i <= nfaces; i++) {53 j = rand() % 6; /* force to range 0 <= j <= 5 */54 printf("+-------+\n" );55 for (k = 0; k < 3; k++)56 printf("|%s|\n", die_faces[(j * 3) + k]);57 printf ("+-------+\n\n");58 }5960 return 0;61 }Эта программа использует простую ASCII-графику для распечатывания подобия грани игральной кости. Вы вызываете ее с числом граней для вывода. Это вычисляется в строке 44 с помощью
atoi()atoi()Ключевой является строка 53, которая преобразует возвращаемое значение
rand()%j * 3die_faces$ ch12-rand 2 /* Вывести две кости */+-------+| || * * || |+-------++-------+| * * || * || * * |+-------+Интерфейс
rand()rand()rand()ch12-rand.c%rand()rand()j = 1+ (int)(10.0*rand()/(RAND_MAX+1.0)); /* для числа от 1 до 10 */
12.6.2. Функции POSIX: random()
и srandom()
random()srandom()BSD 4.3 ввело random() и сопровождающие ее функции. Эти функции используют намного более подходящий генератор случайных чисел, который возвращает 31-разрядное значение. Теперь они входят в расширение XSI, стандартизованное POSIX:
#include /* XSI */ long random(void);void srandom(unsigned int seed);char *initstate(unsigned int seed, char *state, size_t n);char *setstate(char *state);Первые две функции близко соответствуют
rand()srand()long random(void);Возвращает число в диапазоне от 0 до 231-1. (Хотя справочная страница GNU/Linux random(3) говорит между 0 и
RAND_MAXRAND_MAXRAND_MAXvoid srandom(unsigned int seed);Устанавливает начальное число. Если
srandom()char *initstate(unsigned int seed, char *state, size_t n);Инициализирует массив
stateseedsrandom()nstatenrandom()rand()char *setstate(char *state);Устанавливает внутреннее состояние в соответствии с массивом
stateinitstate()Если
initstate()setstate()random()Массив
stateinitstate()random()setstate()initstate()setstate()srandom()ch12-random.crand()1 /* ch12-random.c --- генерация вращения костей с использованием random(). */23 #include 4 #include 5 #include 6 #include 78 char *die_faces[] = { /* Управляет ASCII графика! */ /* ... как раньше ... */32 };3334 /* main --- выводит N различных граней кубиков */3536 int main(int argc, char **argv)37 {38 int nfaces;39 int i, j, k;40 char state[256];41 time_t now;42 /* ... проверка args, вычисление nfaces, как раньше ... */5556 (void)time(&now); /* В качестве начального значения используются время дня и PID */57 (void) initstate((unsigned int)(now + getpid()), state, sizeof state);58 (void)setstate(state);5960 for (i = 1; i <= nfaces; i++) {61 j = random() % 6; /* использовать диапазон 0 <= j <= 5 */62 printf("+-------+\n");63 for (k = 0; k < 3; k++)64 printf("|%s|\n", die_faces[(j * 3) + k]);65 printf("+-------+\n\n");66 }6768 return 0;69 }Включение PID в состав начального значения гарантирует, что вы получите различные результаты, даже если две программы будут запушены в течение одной и той же секунды.
Поскольку она создает последовательности случайных чисел лучшего качества,
random()rand()
12.6.3. Особые файлы /dev/random
и /dev/urandom
/dev/random/dev/urandomКак
rand()srandom()/dev/random[Байты, прочитанные из этого файла, находятся] внутри предполагаемого числа шумовых битов в энтропийном пуле,
/dev/random/dev/random/dev/urandom[Это устройство будет] возвращать столько байтов, сколько затребовано. В результате, если нет достаточной энтропии в энтропийном пуле, возвращаемые значения теоретически уязвимы для криптографической атаки алгоритма, использованного драйвером. Знание того, как это сделать, недоступно в современной не секретной литературе, но теоретически возможно существование подобной атаки. Если для вашего приложения это представляет проблему, вместо этого используйте
/dev/randomДля большинства приложений чтения из
/dev/urandom/dev/urandom1 /* ch12-devrandom.с --- генерирует бросание костей, используя /dev/urandom. */23 #include 4 #include 5 #include 67 char *die_faces[] = { /* Управляет ASCII графика! */ /* ... как ранее ... */31 };3233 /* myrandom --- возвращает данные из /dev/urandom в виде unsigned long */3435 unsigned long myrandom(void)36 {37 static int fd = -1;38 unsigned long data;3940 if (fd == -1)41 fd = open("/dev/urandom", O_RDONLY);4243 if (fd == -1 || read(fd, &data, sizeof data) <= 0)44 return random(); /* отступить */4546 return data;47 }4849 /* main --- вывести N различных граней кубиков */5051 int main(int argc, char **argv)52 {53 int nfaces;54 int i, j, k;55 /* ...проверка args, вычисление nfaces, как ранее... */6869 for (i = 1; i <= nfaces; i++) {70 j = myrandom() % 6; /* обеспечить диапазон 0 <= j <= 5 */71 printf("+-------+\n");72 for (k = 0; k < 3; k++)73 printf("|%s|\n", die_faces[(j * 3) + k]);74 printf("+-------+\n");75 putchar('\n');76 }7778 return 0;79 }Строки 35–47 предоставляют интерфейс вызова функции для
/dev/urandomunsigned long12.7. Расширения метасимволов
Три набора функции возрастающей сложности предусматривают возможность сопоставления с шаблонами групповых символов оболочки. Многим программам нужны такие библиотечные функции. Одним примером является
findfind . -name '*.с' -print--exclude
12.7.1. Простое сопоставление с шаблоном: fnmatch()
fnmatch()Мы начинаем с функции
fnmatch()#include /* POSIX */ int fnmatch(const char *pattern, const char *string, int flags);Эта функция сопоставляет
stringpatternstringpatternFNM_NOMATCHПеременная
flagsТаблица 12.1. Значения флагов для
fnmatch()| Флаг | Только GLIBC | Значение |
|---|---|---|
|
√ | Сопоставление с учетом регистра |
|
√ | Синоним GNU для |
|
√ | Флаг для внутреннего использования GLIBC; не используйте его в своих программах. Подробности см. в fnmatch(3) |
|
Обратный слеш является обычным символом, а не знаком перехода | |
|
Слеш в |
|
|
Начальная точка в |
fnmatch()fnmatch()readdir()struct dirent dp;DIR *dir;char pattern[100];/* ...заполнить шаблон, открыть каталог, проверить ошибки... */while ((dp = readdir(dir)) != NULL) { if (fnmatch(pattern, dir->d_name, FNM_PERIOD) == 0) /* имя файла соответствует шаблону */ else continue; /* не соответствует */}GNU
lsfnmatch()--ignorelsfile_interesting()ls.с2269 /* Возвращает не ноль, если файл в 'next' должен быть перечислен. */22702271 static int2272 file_interesting(const struct dirent *next)2273 {2274 register struct ignore_pattern* ignore;22752276 for (ignore = ignore_patterns; ignore; ignore = ignore->next)2277 if (fnmatch(ignore->pattern, next->d_name, FNM_PERIOD) == 0)2278 return 0;22792280 if (really_all_files2281 || next->d_name[0] !=2282 || (all_files2283 && next->d_name[1] != '\0 '2284 && (next->d_name[1] || next->d_name[2] != '\0')))2285 return 1;22862287 return 0;2288 }Цикл в строках 2276–2278 сопоставляет имя файла со списком шаблонов для игнорируемых файлов. Если один из шаблонов подходит, файл не интересен и
file_interesting()Переменная
all_files-А...really_all_files-а-А...if (/* показать все файлы независимо от их имени (-а) */ OR /* первый символ имени не точка */ OR (/* показать файлы с точкой (-А) */ AND /* в имени файла несколько символов */ AND (/* второй символ не точка */ OR /* третий символ не завершает имя */))) return TRUE;ЗАМЕЧАНИЕ.
fnmatch()
12.7.2. Раскрытие имени файла: glob()
и globfree()
glob()globfree()Функции
glob()globfree()fnmatch()#include /* POSIX */ int glob(const char *pattern, int flags,int (*errfunc)(const char *epath, int eerrno), glob_t *pglob);void globfree(glob_t *pglob);Функция
glob()pattern/usr/*/*.soconst char *patternШаблон для раскрывания.
int flagsФлаги, управляющие поведением
glob()int (*errfunc)(const char *epath, int eerrno)Указатель на функцию для использования при сообщениях об ошибках. Это значение может равняться
NULL(*errfunc)()flagsGLOB_ERRglob()(*errfunc)()opendir()readdir()stat()glob_t *pglobУказатель на структуру
glob_tglob_tglob()typedef struct { /* POSIX */ size_t gl_pathc; /* Число найденных подходящих путей */ char **gl_pathv; /* Список подходящих путей */ size_t gl_offs; /* Слоты для резервирования в gl_pathv */} glob_t;size_t gl_pathcЧисло путей, которые подошли.
char **gl_pathvМассив подходящих путей.
gl_pathv[gl_pathc]NULLsize_t gl_offs«Зарезервированные слоты» в
gl_pathvgl_pathvexecv()execvp()exec()NULLflagsGLOB_DOOFFSВ табл. 12.2 перечислены стандартные флаги для
glob()Таблица 12.2. Флаги для
glob()| Флаг | Значение |
|---|---|
|
Добавить результаты текущего вызова к предыдущим |
|
Зарезервировать места |
|
Добавлять символ / в конец каждого имени, которое обозначает каталог |
|
Если шаблон не соответствует имени какого-нибудь файла, вернуть его без изменений |
|
Рассматривать обратный слеш как обычный символ. Это делает невозможным обозначать метасимволы подстановок |
|
Не сортировать результаты, по умолчанию они сортируются |
GLIBC версия структуры
glob_ttypedef struct { /* GLIBC */ /* Компоненты POSIX: */ size_t gl_pathc; /* Число подходящих путей */ char **gl_pathv; /* Список подходящих путей */ size_t gl_offs; /* Резервируемые в gl_pathv слоты */ /* Компоненты GLIBC: */ int gl_flags; /* Копия флагов, дополнительные флаги GLIBC */ void (*gl_closedir)(DIR *); /* Частная версия closedir() */ struct dirent *(*gl_readdir)(DIR *); /* Частная версия readdir)) */ DIR *(*gl_opendir)(const char *); /* Частная версия opendir)) */ int (*gl_lstat)(const char *, struct stat *); /* Частная версия lstat() */ int (*gl_stat)(const char *, struct stat *); /* Частная версия stat() */} glob_t;Члены структуры следующие:
int gl_flagsКопия флагов. Включает также
GLOB_MAGCHARpatternvoid (*gl_closedir)(DIR *)Указатель на альтернативную версию
closedir()struct dirent *(*gl_readdir)(DIR *)Указатель на альтернативную версию
readdir()DIR *(*gl_opendir)(const char *)Указатель на альтернативную версию
opendir()int (*gl_lstat)(const char *, struct stat*)Указатель на альтернативную версию
lstat()int (*gl_stat)(const char*, struct stat*)Указатель на альтернативную версию
stat()Указатели на альтернативные версии стандартных функций предназначены главным образом для использования в реализации GLIBC; крайне маловероятно, что вы когда-нибудь их используете. Поскольку GLIBC предусматривает поле
gl_flagsglob_tТаблица 12.3. Дополнительные флаги GLIBC для
glob()| Флаг | Значение |
|---|---|
|
Использовать для доступа к каталогам альтернативные функции (см. текст) |
|
Выполнить раскрытие фигурных скобок в стиле |
|
Вставить |
|
Вернуть шаблон, если он не содержит метасимволов |
|
По возможности сопоставлять лишь каталоги. См. текст. |
|
Разрешить соответствие метасимволов наподобие |
|
Выполнить раскрывание тильды в стиле оболочки. |
|
Подобно |
Флаг
GLOB_ONLYDIRglob()GLOB_APPENDgl_offsgl_pathvgl_pathcglob()Возможность многократного вызова
glob()glob()Таблица 12.4. Возвращаемые
glob()| Флаг | Значение |
|---|---|
|
Просмотр остановлен раньше времени, поскольку был установлен |
|
Ни одно имя файла не соответствовало |
|
Была проблема с выделением динамической памяти |
globfree()glob()ch12-glob.сglob()1 /* ch12-glob.c --- демонстрирует glob(). */23 #include 4 #include 5 #include 67 char *myname;89 /* globerr --- выводит сообщение об ошибке для glob() */1011 int globerr(const char *path, int eerrno)12 {13 fprintf(stderr, "%s: %s: %s\n", myname, path, strerror(eerrno));14 return 0; /* let glob() keep going */15 }1617 /* main() --- раскрывает символы подстановки в командной строке и выводит результаты */1819 int main(int argc, char **argv)20 {21 int i;22 int flags = 0;23 glob_t results;24 int ret;2526 if (argc == 1) {27 fprintf(stderr, "usage: %s wildcard ...\n", argv[0]);28 exit(1);29 }3031 myname = argv[0]; /* для globerr() */3233 for (i = 1; i < argc; i++) {34 flags |= (i > 1 ? GLOB_APPEND : 0);35 ret = glob(argv[i], flags, globerr, &results);36 if (ret != 0) {37 fprintf(stderr, "%s: problem with %s (%s),38 stopping early\n", myname, argv[i],39 /* опасно: */ (ret == GLOB_ABORTED ? "filesystem problem" :40 ret == GLOB_NOMATCH ? "no match of pattern" :41 ret == GLOB_NOSPACE ? "no dynamic memory" :42 "unknown problem"));43 break;44 }45 }4647 for (i = 0; i < results.gl_pathc; i++)48 printf("%s\n", results.gl_pathv[i]);4950 globfree(&results);51 return 0;52 }Строка 7 определяет
mynamegloberr()Строки 33–45 являются основой программы. Они перебирают в цикле шаблоны, приведенные в командной строке, вызывая для каждого
glob()Строки 39–41 не являются хорошими; нужно было использовать отдельную функцию, преобразующую целые константы в строки; мы сделали это главным образом ради экономии места. Код наподобие этого может быть сносным для небольших программ, но более крупные должны использовать функцию.
Если вы подумаете о работе, происходящей под капотом (открытие и чтение каталогов, сопоставление шаблонов, динамическое выделение памяти для увеличения списка, сортировка списка), можете качать ценить, как много для вас делает
glob()$ ch12-glob '/usr/lib/x*.so' '../../*.texi'/usr/lib/xchat-autob5.so/usr/lib/xchat-autogb.so../../00-preface.texi../../01-intro.texi../../02-cmdline.texi../../03-memory.texi...Обратите внимание, что нам пришлось взять аргументы в кавычки, чтобы предотвратить их разворачивание оболочкой!
В былые времена, около V6 Unix, для осуществления разворачивания символов подстановки оболочка использовала за кулисами отдельную программу. Эта программа называлась
/etc/globТаким образом глагол «to glob» проник в лексикон Unix со значением «осуществлять разворачивание символов подстановки». Это, в свою очередь, дает нам имена функций
glob()globfree()glob()
12.7.3. Разворачивание слов оболочкой: wordexp()
и wordfree()
wordexp()wordfree()Многие члены комитета POSIX чувствовали, что
glob()echo ~arnoldecho $HOMEecho $(cd ; pwd)glob()#include /* POSIX */ int wordexp(const char *words, wordexp_t *pwordexp, int flags);void wordfree(wordexp_t *wordexp);Эти функции работают сходным с
glob()globfree()wordexp_ttypedef struct { size_t we_wordc; /* Число подходящих слов */ char **we_wordv; /* Список развернутых слов */ size_t we_offs; /* Резервируемые в we_wordv слоты */} wordexp_t;Члены структуры полностью аналогичны описанным ранее для
glob_tКак и для
glob()wordexp()Таблица 12.5. Флаги для
wordexp()| Константа | Значение |
|---|---|
|
Добавить результаты текущего вызова к предыдущим |
|
Зарезервировать |
|
Запретить подстановку команд |
|
Повторно использовать память, на которую указывает |
|
Не молчать при возникновении во время разворачивания ошибок |
|
Неопределенные переменные оболочки должны вызывать ошибку |
Возвращаемое значение равно 0, если все прошло хорошо, или одно из значений из табл. 12.6, если нет.
Таблица 12.6. Возвращаемые значения ошибок для
wordexp()| Константа | Значение |
|---|---|
|
Метасимвол (конец строки, '|', &, ;, <, >, (, ), {, или }) в недопустимом месте |
|
Переменная не определена при установленном |
|
Попытка подстановки команды при установленном |
|
Была проблема с выделением динамической памяти |
|
Синтаксическая ошибка оболочки. |
Мы оставляем вам в качестве упражнения (см. далее) модификацию
ch12-glob.cwordexp()wordfree()$ ch12-wordexp 'echo $HOME' /* Развертывание переменных оболочки */echo/home/arnold$ ch12-wordexp 'echo $HOME/*.gz' /* Переменные и символы подстановки */echo/home/arnold/48000.wav.gz/home/arnold/ipmasq-HOWTO.tar.gz/home/arnold/rc.firewall-examples.tar.gz$ ch12-wordexp 'echo ~arnold' /* Развертывание тильды */echo/home/arnold$ ch12-wordexp 'echo ~arnold/.p*' /* Тильда и символы подстановки */echo/home/arnold/.postitnotes/home/arnold/.procmailrc/home/arnold/.profile$ ch12-wordexp "echo '~arnold/.p*'" /* Кавычки работают */echo~arnold/.p*12.8. Регулярные выражения
Регулярные выражения являются способом описания текстовых шаблонов для сопоставления. Если вы вообще сколько-нибудь использовали GNU/Linux или Unix, вы без сомнения знакомы с регулярными выражениями: они являются фундаментальной частью инструментария программиста Unix. Они неотъемлемы от таких повседневных программ, как
grepegrepsedawkedvivimPOSIX определяет два вида регулярных выражений: базовый и расширенный. Программы типа
grepsededegrepawk#include /* POSIX */ #include int regcomp(regex_t *preg, const char *regex, int cflags);int regexec(const regex_t *preg, const char *string, size_t nmatch, regmatch_t pmatch[], int eflags);size_t regerror(int errcode, const regex_t *preg, char *errbuf, size_t errbuf_size);void regfree(regex_t *preg);Чтобы сопоставить регулярное выражение, нужно сначала откомпилировать строчную версию регулярного выражения. Компиляция преобразует регулярное выражение во внутренний формат. Затем откомпилированная форма исполняется для строки для проверки, совпадает ли она с первоначальным регулярным выражением. Функции следующие.
int regcomp(regex_t *preg, const char *regex, int cflags)Компилирует регулярное выражение
regexregex_tpregcflagsint regexec(const regex_t *preg, const char *string, size_t nmatch, regmatch_t pmatch[], int eflags)Выполняет откомпилированное регулярное выражение в
*pregstring eflagssize_t regerror(int errcode, const regex_t *preg, char *errbuf, size_t errbuf_size)Преобразует ошибку, возвращенную
regcomp()regexec()void regfree(regex_t *preg)Освобождает динамическую память, используемую откомпилированным регулярным выражением в
*pregЗаголовочный файл
regcomp()regexec()REG_regcomp()Таблица 12.7. Флаги для
regcomp()| Константа | Значение |
|---|---|
|
Использовать расширенные регулярные выражения. По умолчанию используются базовые регулярные выражения |
|
Сопоставление |
|
Операторы, заменяющие любой символ, не включают символ конца строки |
|
Информация о начале и конце вложенною шаблона не требуется (см текст) |
Флаги для сопоставления регулярных выражений с помощью
regexec()Таблица 12.8. Флаги дли
regexec()| Константа | Значение |
|---|---|
|
Оператор ^ (начало строки) не сопоставляется |
|
Оператор $ (конец строки) не сопоставляется |
Флаги
REG_NEWLINEREG_NOTBOLREG_NOTEOL• Когда в
cflagsREG_NEWLINE.[^...]$^• Когда в
eflagsREG_NOTBOL^string• Сходным образом, когда в
eflagsREG_NOTEOL$• Когда в
cflagsREG_NEWLINE• Символ конца строки не соответствует '
.• Оператор
^REG_BOL• Оператор
$REG_EOLКогда вы осуществляете построчный ввод/вывод, как в случае с
grepREG_NEWLINEcflags^$REG_NEWLINEСтруктура
regex_ttypedef struct { /* ...здесь внутренний материал... */ size_t re_nsub; /* ...здесь внутренний материал... */} regex_t;В структуре
regmatch_ttypedef struct { /* ...здесь возможный внутренний материал... */ regoff_t rm_so; /* Смещение начала вложенной строки в байтах */ regoff_t rm_eo; /* Смещение первого байта после вложенной строки */ /* ...здесь возможный внутренний материал... */} regmatch_t;Как поле
re_nsubregmatch_t[:пробел:]]+([[:цифра:]]+)[[:пробел:]]+([[:буква:]])+Каждое из двух вложенных выражений в скобках могут соответствовать одному или более символам. Более того, текст, соответствующий каждому вложенному выражению, может начинаться и заканчиваться в произвольных участках строки.
regcomp()re_nsubregexec()pmatchregmatch_tpmatch[0]pmatch[1]pmatch[preg->re_nsub]rm_sorm_eopmatchregexec()nmatch-1pmatchpreg->re_nsubНаконец, флаг
REG_NOSUBregcomp()regexec()Другими словами, если все, что вам нужно знать, это «соответствует ли?», включите
REG_NOSUBВ заключение, как
regcomp()regexec()Таблица 12.9. Коды ошибок
regcomp()regexec()| Константа | Значение |
|---|---|
|
Содержимое ' |
|
Регулярное выражение недействительно |
|
Символу |
|
Фигурные скобки (' |
|
Квадратные скобки (' |
|
В шаблоне использован недействительный элемент сортировки |
|
В шаблоне использован недействительный класс символов |
|
В шаблоне есть завершающий символ |
|
Группирующие скобки (' |
|
Конечная точка в диапазоне не действительна |
|
Функции не хватило памяти |
|
Цифра в ' |
|
Строка не соответствует шаблону |
Для демонстрации регулярных выражений
ch12-grep.cgrep-E-igrepgrepgrep-1 /* ch12-grep.c - Простая версия grep, использующая функции POSIX */23 #define _GNU_SOURCE 1 /* для getline)) */4 #include 5 #include 6 #include 7 #include 8 #include 910 char *myname; /* для сообщений об ошибках */11 int ignore_case = 0; /* опция -i: игнорировать регистр */12 int extended = 0; /* опция -E: использовать расширенные регулярные выражения */13 int errors = 0; /* число ошибок */1415 regex_t pattern; /* шаблон для поиска */1617 void compile_pattern(const char *pat);18 void process(const char *name, FILE *fp);19 void usage(void);Строки 10–15 объявляют глобальные переменные программы. Первый набор (строки 10–13) для опций и сообщений об ошибках. Строка 15 объявляет
pattern21 /* main --- обработка опций, открывание файлов */2223 int main(int argc, char **argv)24 {25 int с;26 int i;27 FILE *fp;2829 myname = argv[0];30 while ((c = getopt(argc, argv, ":iE")) != -1) {31 switch (c) {32 case 'i':33 ignore_case = 1;34 break;35 case 'E':36 extended = 1;37 break;38 case '?':39 usage();40 break;41 }42 }4344 if (optind == argc) /* проверка исправности */45 usage();4647 compile_pattern(argv[optind]); /* компилировать шаблон */48 if (errors) /* ошибка компиляции */49 return 1;50 else51 optind++;В строке 29 устанавливается значение
mynamepatterncompilе_раttern()errorsoptind53 if (optind == argc) /* файлов нет, по умолчанию stdin */54 process("standard input", stdin);55 else {56 /* цикл с файлами */57 for (i = optind; i < argc; i++) {58 if (strcmp(argv[i], "-") == 0)59 process("standard input", stdin);60 else if ((fp = fopen(argv[i], "r")) != NULL) {61 process(argv[i], fp);62 fclose(fp);63 } else {64 fprintf(stderr, "%s: %s: could not open: %s\n",65 argv[0], argv[i], strerror(errno));66 errors++;67 }68 }69 }7071 regfree(&pattern);72 return errors != 0;73 }Строки 53–69 обрабатывают файлы, отыскивая соответствующие шаблону строки. Строки 53–54 обрабатывают случай, когда файлы не указаны: программа читает со стандартного ввода. В противном случае, строки 57–68 обрабатывают в цикле файлы. Строка 58 обрабатывает особый случай '
-75 /* compile_pattern --- компиляция шаблона */7677 void compile_pattern(const char *pat)78 {79 int flags = REG_NOSUB; /* информация о месте совпадения не требуется */80 int ret;81 #define MSGBUFSIZE 512 /* произвольно */82 char error[MSGBUFSIZE];8384 if (ignore_case)85 flags |= REG_ICASE;86 if (extended)87 flags |= REG_EXTENDED;8889 ret = regcomp(&pattern, pat, flags);90 if (ret != 0) {91 (void)regerror(ret, &pattern, error, sizeof error);92 fprintf(stderr, "%s: pattern '%s': %s\n", myname, pat, error);93 errors++;94 }95 }Строки 75–95 определяют функцию
compile_pattern()REG_NOSUBflagsСтроки 84-85 добавляют дополнительные флаги в соответствии с опциями командной строки. Строка 89 компилирует шаблон, а строки 90–94 сообщают о возникших ошибках
97 /* process --- читает строки текста и сопоставляет их с шаблоном */9899 void process(const char *name, FILE *fp)100 {101 char *buf = NULL;102 size_t size = 0;103 char error[MSGBUFSIZE];104 int ret;105106 while (getline(&buf, &size, fp) != -1) {107 ret = regexec(&pattern, buf, 0, NULL, 0);108 if (ret != 0) {109 if (ret != REG_NOMATCH) {110 (void)regerror(ret, &pattern, error, sizeof error);111 fprintf(stderr, "%s: file %s: %s\n", myname, name, error);112 free(buf);113 errors++;114 return;115 }116 } else117 printf("%s: %s", name, buf); /* вывести подходящие строки */118 }119 free(buf);120 }Строки 97–120 определяют функцию
process()getline()getline()getdelim()regexec()REG_NOMATCНЕсли возвращаемое значение равно 0, строка совпала с шаблоном и соответственно строка 117 выводит имя файла и совпавшую строку.
122 /* usage --- вывод сообщения об использовании и выход */123124 void usage(void)125 {126 fprintf(stderr, "usage: %s [-i] [-E] pattern [ files ... ]\n", myname);127 exit(1);128 }Функция
usage()Вот и все! Скромная, но тем не менее полезная версия
grep12.9. Рекомендуемая литература
1. Programming Pearls, 2nd edition, by Jon Louis Bentley Addison-Wesley, Reading, Massachusetts, USA, 2000. ISBN- 0-201-65788-0. См. также веб-сайт этой книги.[131]
Проектирование программы с операторами проверки является одной из главных тем в этой книге.
2. Building Secure Software How to Avoid Security Problems the Right Way, by John Viega and Gary McGraw Addison-Wesley, Reading, Massachusetts, USA, 2001. ISBN: 0-201-72152-X.
Состояния гонки являются одной из многих проблем, о которых нужно побеспокоиться при написании безопасного программного обеспечения. Другой проблемой являются случайные числа. Данная книга рассматривает наряду с другими обе эти проблемы (Мы упоминали о ней в предыдущей главе.)
3. The Art of Computer Programming. Volume 2. Seminumerical Algorithms, 3rd edition, by Donald E. Knuth Addison-Wesley, Reading, Massachusetts, USA, 1998. ISBN- 0-201-89684-2.[132] См также веб-сайт этой книги.[133]
Это классическое справочное руководство по генерации случайных чисел.
4. Random Number Generation and Monte Carlo Methods, 2nd edition, by James E. Gentle Springer-Verlag, Berlin, Germany. 2003. ISBN: 0-387-00178-6.
Данная книга широко освещает методы генерации и тестирования псевдослучайных чисел. Хотя для неё также требуется математическая и статистическая подготовка, уровень не такой высокий, как в книге Кнута. (Благодарим Nelson H.F. Beebe за указание этой ссылки.)
5. sed & awk, 2nd edition, by Dale Dougherty and Arnold Robbins. O'Reilly and Associates, Sebastopol, California, USA, 1997. ISBN: 1-56592-225-5.
Эта книга осторожно вводит в регулярные выражения и обработку текста, начиная с
grepsedawk6. Mastering Regular Expressions, 2nd edition, by Jeffrey E.F. Friedl. O'Reilly and Associates, Sebastopol, California, USA, 2002.[134] ISBN: 0-59600-289-0.
Регулярные выражения являются важной частью Unix. Чтобы научиться заменять, вырезать и распределять текст с использованием регулярных выражений, мы рекомендуем эту книгу
7. Руководство для GNU
grepinfo grepgrep12.10. Резюме
• Операторы проверки предоставляют способ сделать утверждения о предполагаемом состоянии программы. Они являются полезным инструментом для проектирования и отладки и обычно должны оставаться в коде изделия. Однако, будьте внимательны, чтобы не перепутать операторы проверки с проверками возможных ошибок времени исполнения.
• Функции
memXXX()strXXX()memcpy()memmove()• Временные файлы полезны во многих приложениях. Функции API
tmpfile()mkstemp()TMPDIR/tmp• Функция
abort()SIGABRT•
setjmp()longjmp()sigsetjmp()siglongjmp()• Случайные числа полезны для множества приложений. Большинство программ используют псевдослучайные числа — последовательности номеров, которые кажутся случайными, но которые могут быть воспроизведены с помощью одного и того же начального значения.
rand()srand()rand()random()srandom()rand()srand()/dev/random/dev/urandom• Три функции API предоставляют все более мощные возможности для развертывания метасимволов (подстановки символов).
•
fnmatch()•
glob()glob()glob()wordexp()glob()•
wordexp()glob()• Функции
regcomp()regexec()Упражнения
1. Используйте
read()memcmp()cmp2. Используйте макрос
getc() cmp3. (Средней трудности) Рассмотрите функции
fgets() getline()memcpy()fgets()4. (Трудное) Найдите исходный код GLIBC версии
memcmp()5. Проверьте свою память. Как
tmpfile()6. Используя
mkstemp()fdopen()tmpfile()7. Опишите преимущества и недостатки использования
unlink()mkstemp()mkstemp()8. Напишите свою версию
mkstemp()mktemp()open()mkstemp()9. Программы, использующие
mkstemp()10. (Трудное) Даже с урезанной очисткой при обработке сигнала все еще имеется состояние гонки. Есть небольшое окно между созданием временного файла функцией
mkstemp()11. Попробуйте откомпилировать и запустить
ch12-setjmp.c12. Посмотрите файл
/usr/src/libc/gen/sleep.csleep()sleep()alarm()SIGALARM13. Посмотрите справочную страницу lrand48(3) на системе GNU/Linux или System V. Выглядит ли этот интерфейс более простым или трудным для использования, чем
random()14. Возьмите
ch08-nftw.cnftw()--exclude=pattern15. (Трудное) Почему GLIBC нужны указатели на альтернативные версии функций стандартных каталогов и
stat()16. Измените
ch12-glob.cwordexp()wordexp()17. Стандартная
grepch12-grep.c18. Посмотрите справочную страницу grep(1). Добавьте к
ch12-grep.c-e-s-v19. Напишите простую замещающую программу:
subst [-g] шаблон подстановка [файлы ...]Она должна читать текстовые строки из указанных файлов или из стандартного ввода, если они не указаны. Каждая строка должна сравниваться на соответствие шаблону. Если обнаружено соответствие, оно должно замещаться подстановкой.
Если указана опция
-g
Глава 13
Интернационализация и локализация
Ранние вычислительные системы обычно для своего вывода (приглашений, сообщений об ошибках) и ввода (ответы на запросы, такие, как «да» и «нет») использовали английский язык. Это было верно для систем Unix вплоть до середины 1980-х. В конце 80-х, начиная с первого стандарта ISO для С и продолжая стандартами POSIX 1990-х и современным стандартом POSIX, были разработаны возможности для работы программ на нескольких языках без необходимости поддержки нескольких версий одной и той же программы. Данная глава описывает, как современные программы должны справляться с многоязычными проблемами.
13.1. Введение
Центральной концепцией является окружение, место, в котором работает программа. Локали содержат в себе следующие сведения: локальный набор символов; сведения о формате отображения даты и времени; форматирование и отображение денежных сумм; форматирование и отображение числовых значений (с или без разделителей тысяч, какой символ используется в качестве разделителя дробной части числа и т.д.).
Интернационализация является процессом написания (или изменения) программы таким образом, что она может работать с различными локалями. Локализация является процессом приспособления интернационализированной программы для определенной локали. Часто вместо этих терминов используют сокращения i18n и l10n соответственно. (Числовое значение указывает, сколько букв в середине слова, а эти сокращения имеют небольшое сходство с полными терминами.[136] Их также гораздо легче набирать.) Другим часто встречающимся термином является поддержка родного языка, обозначаемая как NLS[137]; NLS обозначает программную поддержку для i18n и l10n.
Кроме того, некоторые люди используют термин глобализация (сокращенно g10n) для обозначения процесса подготовки всех возможных локализаций для интернационализированной программы. Другими словами, подготовки программы для глобального использования.
Возможности NLS существуют на двух уровнях. Первым уровнем является библиотека С. Она предоставляет сведения о локали; процедуры для обработки большей части низкоуровневых подробностей работы по форматированию даты/времени, числовых и денежных значений; и процедуры для корректного для данной локали сопоставления регулярных выражений и классификации символов и сравнений. Именно возможности библиотеки появляются в стандартах С и POSIX.
На уровне приложения GNU
gettext
предоставляет команды и библиотеку для локализации программы: т.е. для возможности вывода сообщений на одном или более естественных языках. GNU gettext
основана на плане, первоначально разработанном Sun Microsystems для Solaris[138]; однако, она была реализована с нуля и теперь предоставляет расширения к первоначальному gettext
Solaris. GNU gettext
является стандартом де-факто для локализации программ, особенно в мире GNU.
В дополнение к локалям и
gettext
стандарт С предоставляет возможности для работы с несколькими наборами символов и с их кодировками — способом представления больших наборов символов с помощью меньшего числа байтов. Мы кратко затронем эти проблемы в конце главы.
13.2. Локали и библиотека С
Специфичное для локали поведение управляется посредством установки переменных окружения, описывающих, какую локаль (локали) использовать для той или иной информации. Число доступных локалей, предлагаемых каждой конкретной операционной системой, колеблется от менее чем десяти на некоторых коммерческих системах Unix до сотен локалей на системах GNU/Linux. ('
locale -a
' выводит полный список доступных локалей.)
Гарантируется существование двух локалей, «С» и «POSIX». Они действуют в качестве локали по умолчанию, предоставляя окружение 7-разрядного ASCII, поведение которого такое же, как на традиционных системах Unix без поддержки локалей. В противном случае, локали обозначают язык, страну, а также могут включать сведения о наборе символов. Например, '
it_IT
' используется для итальянского языка в Италии с использованием системного набора символов по умолчанию, a 'it_IT.UTF-8
' использует кодировку UTF-8 для набора символов Unicode.
Дополнительные подробности об именах локалей можно найти в справочной странице GNU/Linux setlocale(3). Обычно дистрибутивы GNU/Linux устанавливают для системы локаль по умолчанию при ее установке, основываясь на языке, выбранном тем кто устанавливал ее, и пользователям больше не приходится об этом беспокоиться.
13.2.1. Категории локалей и переменные окружения
Заголовочный файл
определяет функции и структуры локали. Категории локали определяют разновидности информации, которые будут для программы зависимы от локали. Категории доступны в виде набора именованных констант. Они перечислены в табл. 13.1.
Таблица 13.1. Константы категорий локалей ISO С, определенные в
Категория
Значение
LC_ALL
Эта категория включает всю возможную информацию локали. Она состоит из оставшейся части элементов этой таблицы
LC_COLLATE
Категория для сравнения строк (обсуждаемого ниже) и областей регулярных выражений
LC_CTYPE
Категория для классификации символов (заглавные, строчные и т.д.) Это влияет на сопоставление регулярных выражений и функции isXXX()
в
LC_MESSAGES
Категория для специфичных для локали сообщений. Эта категория вступает в игру с GNU gettext
, которая обсуждает далее в главе
LC_MONETARY
Категория для форматирования денежной информации, такой, как локальные и международные символы для местной валюты (например, $ против USD для доллара США), форматирования отрицательных величин и т.д.
LC_NUMERIC
Категория для форматирования числовых значений
LC_TIME
Категория для форматирования дат и времени
Эти категории определены различными стандартами. Некоторые системы могут поддерживать дополнительные категории, такие, как
LC_TELEPHONE
или LC_ADDRESS
. Однако, они не стандартизованы; любой программе, которой нужно их использовать, но которая все равно должна быть переносимой, следует использовать #ifdef
для окружения соответствующих разделов.
По умолчанию, программы С и библиотека С ведут себя так, как если бы они находились в локали «С» или «POSIX» для обеспечения обратной совместимости со старыми системами. Однако, вызвав
setlocale()
(как описано ниже), программа может включить действие локали. После того, как программа это сделала, пользователь может, установив переменные окружения, включать и выключать возможности локали, которые будет иметь программа.
Переменные окружения имеют те же самые имена, что и перечисленные в табл. 13.1 категории локалей. Таким образом, команда —
export LC_NUMERIС=en_DK LC_TIME=C
— определяет, что числа должны выводиться в соответствии с локалью '
en_DK
' (английский язык в Дании), но что значения даты и времени должны выводиться в соответствии с обычной локалью 'С
'. (Этот пример просто иллюстрирует, что вы можете указывать для различных категорий различные локали; это не является чем-то обязательным, что вы должны делать.)
Переменная окружения
LC_ALL
перекрывает все другие переменные LC_xxx
. Если LC_ALL
не установлена, библиотека ищет определенные переменные (LC_CTYPE
, LC_MONETARY
и т.д.). Наконец, если ни одна из них не установлена, библиотека ищет переменную LANG
. Вот небольшая демонстрация с использованием gawk
:
$ unset LC_ALL LANG /* Удалить переменные по умолчанию */
$ export LС_NUMERIC=en_DK LC_TIME=C
/* Европейские числа, дата и время по умолчанию */
$ gawk 'BEGIN { print 1.234 ; print strftime() }'
/* Вывести число, текущие дату и время */
1,234
Wed Jul 09 09:32:18 PDT 2003
$ export LC_NUMERIC=it_IT LC_TIME=it_IT
/* Итальянские числа, дата и время */
$ gawk 'BEGIN { print 1.234 ; print strftime() }'
/* Вывести число, текущие дату и время */
1,234
mer lug 09 09:32:40 PDT 2003
$ export LC_ALL=C /* Установить перекрывающую переменную */
$ gawk 'BEGIN { print 1.234 ; print strftime() }'
/* Вывести число, текущие дату и время */
1.234
Wed Jul 09 09:33:00 PDT 2003
Для
awk
стандарт POSIX констатирует, что числовые константы в исходном коде всегда используют в качестве десятичного разделителя '.
' тогда как числовой вывод следует правилам локали).
Почти все GNU версии стандартных утилит Unix могут использовать локали. Таким образом, особенно на системах GNU/Linux, установка этих переменных позволяет вам контролировать поведение системы[139].
13.2.2. Установка локали: setlocale()
Как уже упоминалось, если вы ничего не делаете, программы на С и библиотека С ведет себя так, как если бы использовалась локаль «С». Функция
setlocale()
устанавливает соответствующую локаль:
#include /* ISO С */
char *setlocale(int category, const char *locale);
Аргумент
category
является одной из категорий, описанных в разделе 13.2.1 «Категории локалей и переменные окружения». Аргумент locale
является строкой, именующей используемую для этой категории локаль. Когда locale
является пустой строкой (""
), setlocale()
проверяет соответствующие переменные окружения.
Если
locale
равно NULL
, сведения о локали не изменяются. Вместо этого функция возвращает строку, представляющую текущую локаль для данной категории.
Поскольку каждая категория может быть установлена индивидуально, автор приложения решает, насколько будет программа использовать локаль. Например, если
main()
делает лишь это —
setlocale(LC_TIME, "");
/* Использование локали только для времени и все */
— тогда, независимо от установленных в окружении других переменных
LC_xxx
, локали подчиняются лишь функции времени и даты. Все остальные действуют так, как если бы программа по-прежнему работала в локали «С». Сходным образом вызов:
setlocale(LC_TIME, "it_IT"); /* Время всегда итальянское */
заменяет переменную окружения
LC_TIME
(также, как LC_ALL
), заставляя программу использовать для вычислений времени/даты данные для Италии. (Хотя Италия может быть прекрасным местом, программам лучше использовать ""
, чтобы они могли корректно работать везде; этот пример предназначен лишь для объяснения того, как работает setlocale()
.)
Можно индивидуально вызывать
setlocale()
для каждой категории, но простейшим способом является установка всего одним махом:
/* Находясь в Риме, вместо «всего» делайте все как римляне. :-) */
setlocale(LC_ALL, "");
Возвращаемое
setlocale()
значение является текущей установкой локали. Это либо строковое значение, переданное в предыдущем вызове, либо непрозрачное значение, представляющее используемую вначале локаль. Это самое значение может быть затем передано обратно setlocale()
. Для последующего использования возвращаемое значение должно быть скопировано в локальное хранилище, поскольку это указатель на внутренние данные.
char *initial_locale;
initial_locale = strdup(setlocale(LC_ALL, "")); /* сохранить копию */
...
(void)setlocale(LC_ALL, initial_locale); /* восстановить ее */
Здесь мы сохранили копию, использовав функцию POSIX
strdup()
(см. раздел 3.2.2 «Копирование строк: strdup()
»).
13.2.3. Сравнение строк: strcoll()
и strxfrm
()
Знакомая функция
strcmp()
сравнивает две строки, возвращая отрицательное, нулевое или положительное значения, если первая строка меньше, равна или больше второй. Это сравнение основано на числовых значениях символов в машинном наборе символов. Из-за этого результаты strcmp()
никогда не изменяются.
Однако, при наличии локалей простого числового сравнения недостаточно. Каждая локаль определяет для содержащихся в ней символов последовательность сортировки, другими словами, относительный порядок символов внутри локали. Например, в простом 7-битном ASCII у двух символов '
А
' и 'а
' десятичные значения равны 65 и 97 соответственно. Соответственно, во фрагменте
int i = strcmp("А", "a");
i
имеет отрицательное значение. Однако, в локали "en_US.UTF-8
" 'A
' идет после 'a
', а не перед ним. Таким образом, использование strcmp()
для приложений, использующих локаль, является плохой мыслью, мы могли бы сказать, что она возвращает игнорирующий локаль ответ.
Функция
strcoll()
(string collate — сортировка строк) существует для сравнения строк с использованием локали:
#include /* ISO С */
int strcoll(const char *s1, const char *s2);
Она возвращает такие же отрицательные/нулевые/положительные значения, что и
strcmp()
. Следующая программа, ch13-compare.c
, интерактивно демонстрирует разницу:
1 /* ch13-compare.с --- демонстрация strcmp() против strcoll() */
2
3 #include
4 #include
5 #include
6
7 int main(void)
8 {
9 #define STRBUFSIZE 1024
10 char locale[STRBUFSIZE], curloc[STRBUFSIZE];
11 char left[STRBUFSIZE], right[STRBUFSIZE];
12 char buf[BUFSIZ];
13 int count;
14
15 setlocale(LC_ALL, ""); /* установить локаль */
16 strcpy(curloc, setlocale(LC_ALL, NULL)); /* сохранить ее */
17
18 printf("--> "); fflush(stdout);
19 while (fgets(buf, sizeof buf, stdin) != NULL) {
20 locale[0] = '\0';
21 count = sscanf(buf, "%s %s %s", left, right, locale);
22 if (count < 2)
23 break;
24
25 if (*locale) {
26 setlocale(LC_ALL, locale);
27 strcpy(curloc, locale);
28 }
29
30 printf("%s: strcmp(\"%s\", \"%s\") is %d\n", curloc, left,
31 right, strcmp(left, right));
32 printf("%s: strcoll(\"%s\", \"%s\") is %d\n", curloc, left,
33 right, strcoll(left, right));
34
35 printf("\n--> "); fflush(stdout);
36 }
37
38 exit(0);
39 }
Программа читает входные строки, состоящие из двух сравниваемых слов и необязательной локали, использующейся для сравнения. Если локаль дана, она становится локалью для последующих элементов. Программа начинает с любой локалью, которая установлена в окружении.
Массив
curloc
сохраняет текущую локаль для вывода результатов; left
и right
являются левым и правым сравниваемыми словами (строки 10–11). Основную часть программы составляет цикл (строки 19–36), который читает строки и выполняет работу. Строки 20–23 разделяют входную строку, locale
инициализируется пустой строкой, если третья строка не предусмотрена.
Строки 25–28 устанавливают новую локаль, если она приведена. Строки 30–33 выводят результаты сравнения, а строка 35 приглашает для дальнейшего ввода. Вот демонстрация:
$ ch13-compare /* Запуск программы */
--> ABC abc /* Ввести два слова */
С: strcmp("ABC", "abc") is -1 /* Программа началась в локали "С" */
С: strcoll("ABC", "abc") is -1 /* В локали "С" идентичные рез-ты */
--> ABC abc en_US /* Слова те же, локаль "en_US" */
en_US: strcmp("ABC", "abc") is -1 /* strcmp() без изменений */
en_US: strcoll("ABC", "abc") is 2 /* рез-ты strcoll() изменились' */
--> ABC abc en_US.UTF-8 /* Слова те же, локаль "en_US.UTF-8" */
en_US.UTF-8: strcmp("ABC", "abc") is -1
en_US. UTF-8: strcoll("ABC", "abc") is 6
/* Другое значение, все еще положительное */
--> junk JUNK /* Новые слова */
en_US.UTF-8: strcmp("junk", "JUNK") is 1 /* предыдущая локаль */
en_US.UTF-8: strcoll("junk", "JUNK") is -6
Эта программа ясно показывает различие между
strcmp()
и strcoll()
. Поскольку strcmp()
работает в соответствии с числовыми значениями символов, она всегда возвращает тот же самый результат, strcoll()
понимает проблемы сортировки, и ее результат меняется в соответствии с локалью. Мы видим, что в обеих локалях en_US
заглавные буквы идут после строчных.
ЗАМЕЧАНИЕ. Специфическая для локали сортировка строк является проблемой также и для сопоставления регулярных выражений. Регулярные выражения допускают диапазоны символов внутри выражений со скобками, такие, как '
[a-z]
' или '["-/]
'. Точное значение такой конструкции (символы, численно располагающиеся между начальной и конечной точками включительно) определено лишь для локалей «С» и «POSIX»
Для локалей, не являющихся ASCII, такие диапазоны как '
[a-z]
' могут соответствовать также и заглавным буквам, а не только строчным! Диапазон '["-/]
' действителен в ASCII, но не в "en_US.UTF-8
".
Долговременным наиболее переносимым решением является использование классов символов POSIX, таких, как '
[[:lower:]]
' и '[[:punct:]]
'. Если вам кажется, что нужно использовать выражения с диапазонами на системах, использующих локали, и на более старых системах, не использующих их, без изменения своей программы, решение заключается в применении грубой силы и индивидуальном перечислении каждого символа внутри скобок. Это неприятно, но это работает.
Основанная на локалях сортировка потенциально дорогостоящая. Если вы ожидаете большого числа сравнений, где по крайней мере одна из строк не будет изменяться или где значения строк будут сравниваться друг с другом по несколько раз (как при сортировке списка), следует рассмотреть использование функции
strxfrm()
для преобразования своих строк для использования с strcmp()
. Функция strxfrm()
объявлена следующим образом:
#include /* ISO С */
size_t strxfrm(char *dest, const char *src, size_t n);
Идея в том, что
strxfrm()
преобразует первые n символов src
, помещая их в dest
. Возвращаемое значение является числом символов, необходимых для сохранения преобразованных символов. Если она превышает n, содержимое dest
«неопределенно».
Стандарт POSIX явным образом разрешает устанавливать в
n
ноль, а в dest NULL
. В этом случае strxfrm()
возвращает размер массива, необходимого для сохранения преобразованной версии src
(не включая завершающий символ '\0
'). Предполагается, что это значение впоследствии будет использовано с malloc()
для создания массива dest
или для проверки размера предопределенных границ массива (При этом, очевидно, src
должен иметь завершающий нулевой байт.) Этот фрагмент иллюстрирует использование strxfrm()
:
#define STRBUFSIZE ...
char s1[STRBUFSIZE], s2[STRBUFSIZE]; /* Оригинальные строки */
char s1x[STRBUFSIZE], s2x[STRBUFSIZE]; /* Преобразованные копии */
size_t len1, len2;
int cmp;
/* ... заполнить s1 и s2 ... */
len1 = strlen(s1);
len2 = strlen(s2);
if (strxfrm(s1x, s1, len1) >= STRBUFSIZE ||
strxfrm(s2x, s2, len2) >= STRBUFSIZE)
/* слишком большой, восстановить */
cmp = strcmp(s1x, s2x);
if (cmp == 0)
/* равны */
else if (cmp < 0)
/* s1 < s2 */
else
/* s1 > s2 */
Для одноразовых сравнений, возможно, быстрее непосредственно использовать
strcoll()
. Но если строки будут сравниваться несколько раз, более быстрым будет использование сначала strxfrm()
, а затем strcmp()
с преобразованными значениями. Функций для локали, соответствующих strncmp()
или strcasecmp()
, нет.
13.2.4. Числовое и денежное низкоуровневое форматирование: localeconv()
Корректное форматирование числовых и денежных значений требует значительной низкоуровневой информации. Указанная информация доступна в
struct lconv
, которую получают с помощью функции localeconv()
:
#include /* ISO С */
struct lconv *localeconv(void);
Подобно функции
ctime()
, эта функция возвращает указатель на внутренние статические данные. Следует сделать копию возвращенных данных, поскольку последующие вызовы могут возвратить другие значения, если локаль изменилась. Вот struct lconv
(слегка сжатая), непосредственно из GLIBC
:
struct lconv {
/* Числовая (не денежная) информация. */
char *decimal_point; /* Разделитель десятичной дроби. */
char *thousands_sep; /* Разделитель тысяч. */
/* Каждый элемент является числом цифр в каждой группе;
элементы с большими индексами оставлены дальше. Элемент со
значением CHAR_MAX означает, что дальнейшая группировка не
производится. Элемент со значением 0 означает, что предыдущий
элемент используется для всех оставшихся групп. */
char *grouping;
/* Денежная информация. */
/* Первые три символа являются символами валют из ISO 4217.
Четвертый символ является разделителем. Пятый символ '\0'. */
char *int_curr_symbol;
char *currency_symbol; /* Символ местной валюты. */
char *mon_decimal_point; /* Символ десятичной точки. */
char *mon_thousands_sep; /* Разделитель тысяч. */
char *mon_grouping; /* Аналогично элементу 'группировки' (выше). */
char *positive_sign; /* Знак для положительных значений. */
char *negative_sign; /* Знак для отрицательных значений. */
char int_frac_digits; /* Международные цифры дробей. */
char frac_digits; /* Местные цифры дробей. */
/* 1, если символ валюты перед положит, значением, 0, если после. */
char p_cs_precedes;
/* 1, если символ валюты отделяется от положит, значения пробелом. */
char p_sep_by_space;
/* 1, если символ валюты перед отриц. значением, 0, если после. */
char n_cs_precedes;
/* 1, если символ валюты отделяется от отриц. значения пробелом. */
char n_sep_by_space;
/* Размещение положительного и отрицательного знака:
0 Количество и символ валюты окружены скобками.
1 Строка знака перед количеством и символом валюты.
2 Строка знака за количеством и символом валюты.
3 Строка знака непосредственно перед символом валюты.
4 Строка знака непосредственно после символа валюты. */
char p_sign_posn;
char n_sign_posn;
/* 1, если int_curr_symbol до положит. значения, 0, если после. */
char int_p_cs_precedes;
/* 1, если int_curr_symbol отделен от положит, знач. пробелом. */
char int_p_sep_by_space;
/* 1, если int_curr_symbol перед отриц. значением, 0, если после. */
char int_n_cs_precedes;
/* 1, если int_curr_symbol отделен от отриц. знач. пробелом. */
char int_n_sep_by_space;
/* Размещение положительного и отрицательного знака:
0 Количество и int_curr_symbol окружены скобками.
1 Строка знака до количества и int_curr_symbol.
2 Строка знака после количества и int_curr_symbol.
3 Строка знака непосредственно до int_curr_symbol.
4 Строка знака непосредственно после int_curr_symbol. */
char int_p_sign_posn;
char int_n_sign_posn;
};
Комментарии показывают довольно ясно, что происходит. Давайте посмотрим на несколько первых полей
struct lconv
:
decimal_point
Используемый символ разделителя десятичной дроби. В Соединенных Штатах и других англоязычных странах это точка, но во многих странах используется запятая.
thousands_sep
Символ, используемый для разделения каждых 3 цифр значения.
grouping
Массив однобайтных целых значений. Каждый элемент указывает, сколько цифр в группе. Как сказано в комментарии,
CHAR_MAX
означает, что дальше группировка не используется, а 0 означает повторное использование последнего элемента (Далее в главе мы покажем пример кода.)
int_curr_symbol
Это международный символ для местной валюты. Например, 'USD' для доллара США.
currency_symbol
Локальный символ для местной валюты. Например, $ для доллара США.
mon_decimal_point
, mon_thousands_sep
, mon_grouping
Соответствуют предыдущим полям, предоставляя те же сведения, но для денежных сумм.
Большая часть оставшихся значений не имеет значения для повседневного программирования. Следующая программа,
ch13-lconv.c
, выводит некоторые из этих значений, чтобы дать вам представление, для какого рода сведений они используются:
/* ch13-lconv.c --- показывает некоторые компоненты struct lconv */
#include
#include
#include
int main(void) {
struct lconv l;
int i;
setlocale(LC_ALL, "");
l = *localeconv();
printf("decimal_point = [%s]\n", l.decimal_point);
printf("thousands_sep = [%s]\n", l.thousands_sep);
for (i = 0; l.grouping[i] != 0 && l.grouping[i] != CHAR_MAX; i++)
printf("grouping[%d] = [%dj\n", i, l.grouping[i]);
printf("int_curr_symbol = [%s]\n", l.int_curr_symbol);
printf("currency_symbol = f%s]\n", l.currency_symbol);
printf("mon_decimal_point = f%s]\n", l.mon_decimal_point);
printf("mon_thousands_sep = [%s]\n", l.mon_thousands_sep);
printf("positive_sign = [%s]\n", l.positive_sign);
printf("negative_sign = [%s]\n", l.negative_sign);
}
Неудивительно, при запуске в различных локалях мы получаем различные результаты.
$ LC_ALL=en_US ch13-lconv /* Результаты для Соединенных Штатов */
decimal_point = [.]
thousands_sep = [,]
grouping[0] = [3]
grouping[1] = [3]
int_curr_symbol = [USD ]
currency_symbol = [$]
mon_decimal_point = [.]
mon_thousands_sep = [,]
positive_sign = []
negative_sign = [-]
$ LC_ALL=it_IT ch13-lconv /* Результаты для Италии */
decimal_point = [.]
thousands_sep = []
int_curr_symbol = []
currency_symbol = []
mon_decimal_point = []
mon_thousands_sep = []
positive_sign = []
negative_sign = []
Обратите внимание, что значение
int_curr_symbol
в локали "en_US
" включает завершающий символ пробела, который служит для отделения символа от последующего денежного значения.
13.2.5. Высокоуровневое числовое и денежное форматирование: strfmon()
и printf()
После рассмотрения всех полей
struct lconv
вы можете поинтересоваться: «Нужно ли мне на самом деле выяснять, как использовать все эти сведения, просто для форматирования денежного значения?» К счастью, ответом является «нет».[140] Функция strfmon()
делает за вас всю работу:
#include /* POSIX */
ssize_t strfmon(char *s, size_t max, const char *format, ...);
Эта функция во многом подобна
strftime()
(см. раздел 6.1.3.2 «Сложное форматирование времени: strftime()
»), используя format
для копирования символов букв и форматированных числовых значений в s
, помещая в нее не более max символов. Следующая простая программа, ch13-strfmon.c
, демонстрирует работу strfmon()
:
/* ch13-strfmon.c --- демонстрация strfmon() */
#include
#include
#include
int main(void) {
char buf[BUFSIZ];
double val = 1234.567;
setlocale(LC_ALL, "");
strfmon(buf, sizeof buf, "You owe me %n (%i)\n", val, val);
fputs(buf, stdout);
return 0;
}
При запуске в двух различных локалях она выдает такой результат:
$ LC_ALL=en_US ch13-strfmon /* В Соединенных Штатах */
You owe me $1,234.57 (USD 1,234.57)
$ LC_ALL=it_IT ch13-strfmon /* В Италии */
You owe me EUR 1.235 (EUR 1.235)
Как вы можете видеть,
strfmon()
подобна strftime()
, копируя обычные символы в буфер назначения без изменений и форматируя аргументы в соответствии со своими собственными спецификациями форматирования. Их всего три.
%n
Вывести национальное (т.е. местное) представление значения валюты.
%i
Вывести международное представление значения валюты.
%%
Вывести символ '%
'.
Форматируемые значения должны иметь тип
double
. Разницу между %n
и %i
мы видим в локали "en_US
": %n
использует символ $
, тогда как %i
использует USD, которая означает «доллары США».
Гибкость — и соответственно определенная сложность — сопровождают многие функции API, разработанные для POSIX, и
strfmon()
не является исключением. Как и с printf()
, несколько необязательных элементов, которые могут быть между %
и i
или n
, обеспечивают повышенный контроль. Полные формы следующие:
%[флаги][ширина поля][#точность_слева][.точность_справа]i
%[флаги][ширина поля][#точность_слева][.точность_справа]n
%% /* Не допускаются поля флагов, ширины и т.д. */
Флаги перечислены в табл. 13.2.
Таблица 13.2. Флаги для
strfmon()
Флаг
Значение
=с
Использовать символ с в качестве символа числового заполнения слева. Символом по умолчанию является пробел. Обычной альтернативой является 0
^
Запретить использование символа группировки (например, запятой в Соединенных Штатах)
(
Отрицательные значения заключать в скобки. Несовместим с флагом +
+
Обрабатывать положительные/отрицательные значения обычным образом. Использовать положительные и отрицательные знаки локали. Несовместим с флагом (
!
Не включать символ валюты. Этот флаг полезен, если вы хотите использовать strfmon()
для более гибкого форматирования обычных чисел, чем это предусматривает sprintf()
-
Выровнять результат слева. По умолчанию используется выравнивание справа. Этот флаг не действует без указания ширины поля
Ширина поля является строкой десятичных цифр, представляющих минимальную ширину. По умолчанию использует столько символов, сколько необходимо, основываясь на оставшейся части спецификации. Значения, меньшие ширины поля, дополняются пробелами слева (или справа, если указан флаг '
-
').
Точность слева состоит из символа
#
и строки десятичных цифр. Она указывает минимальное число цифр, которые должны быть слева от десятичного символа-разделителя дробной части[141]; если преобразованное значение меньше этого, результат выравнивается символом числового заполнения. По умолчанию используется пробел, однако для его изменения можно использовать флаг =
. Символы группировки не включаются в общий счет.
Наконец, точность справа состоит из символа '
.
' и строки десятичных цифр. Она указывает, с каким числом значащих цифр округлить значение до форматирования. По умолчанию используются поля frac_digits
и int_frac_digits
в struct lconv
. Если это значение равно 0, десятичная точка не выводится.
strfmon()
возвращает число символов, помещенных в буфер, не включая завершающий нулевой байт. Если недостаточно места, функция возвращает -1 и устанавливает errno
в E2BIG
.
Помимо
strfmon()
, POSIX (но не ISO С) предусматривает специальный флаг — символ одинарной кавычки, '
— для форматов printf()
%i
, %d
, %u
, %f
, %F
, %g
и %G
. В локалях, имеющих разделитель тысяч, этот флаг добавляет и его. Следующая простая программа, ch13-quoteflag.c
, демонстрирует вывод:
/* ch13-quoteflag.c --- демонстрация флага кавычки printf */
#include
#include
int main(void) {
setlocale(LC_ALL, ""); /* Это нужно, иначе не будет работать */
printf("%'d\n", 1234567);
return 0;
}
Вот что происходит для двух различных локалей: в одной есть разделитель тысяч, в другой нет:
$ LC_ALL=C ch13-quoteflag /* Обычное окружение без разделителя */
1234567
$ LC_ALL=en_US ch13-quoteflag /* Локаль с разделителем (англ.) */
1,234,567
На время написания лишь GNU/Linux и Solaris поддерживают флаг
'
. Дважды проверьте справочную страницу printf(3) на своей системе.
13.2.6. Пример: форматирование числовых значений в gawk
gawk
реализует свои собственные версии функций printf()
и sprintf()
. Для полного использования локали gawk
должен поддерживать флаг '
, как в С. Следующий фрагмент из файла builtin.c
в gawk
3.1.4 показывает, как gawk
использует struct lconv
для числового форматирования:
1 case 'd':
2 case 'i':
3 ...
4 tmpval = force_number(arg);
5
6 ...
7 uval = (uintmax_t)tmpval;
8 ...
9 ii = jj = 0;
10 do {
11 *--cp = (char)('0' + uval % 10);
12 #ifdef HAVE_LOCALE_H
13 if (quote_flag && loc.grouping[ii] && ++jj == loc.grouping[ii]) {
14 *--cp = loc.thousands_sep[0]; /* XXX - предположение, что это один символ */
15 if (loc.grouping[ii+1] == 0)
16 jj = 0; /* продолжить использовать текущий val в loc.grouping [ii] */
17 else if (loc.grouping[ii+1] == CHAR_MAX)
18 quote_flag = FALSE;
19 else {
20 ii++;
21 jj = 0;
22 }
23 }
24 #endif
25 uval /= 10;
26 } while (uval > 0);
(Номера строк даны относительно начала фрагмента.) Некоторые части кода, не имеющие отношения к обсуждению, были опущены, чтобы облегчить фокусировку на важных частях.
Переменная
loc
, используемая в строках 13–17, представляет struct lconv
. Она инициализируется в main()
. Здесь для нас интерес представляет loc.thousands_sep
, который является символом разделителя тысяч, и loc.grouping
, который является массивом, описывающим число цифр между разделителями. Нулевой элемент означает «использовать для всех последующих цифр значение предыдущего элемента», а значение CHAR_MAX
означает «прекратить вставку разделителей тысяч».
С таким введением, давайте посмотрим на код. Строка 7 устанавливает
uval
, которая является беззнаковой версией форматируемого значения. ii
и jj
отслеживают положение в loc.grouping
и число цифр в текущей группе, которые были преобразованы, соответственно[142]. quote_flag
равен true, когда в спецификации преобразования был отмечен символ '
.
Цикл
do-while
генерирует символы цифр в обратном порядке, заполняя буфер с конца к началу. Каждая цифра создается в строке 11. Затем строка 25 делится на 10 путем смещения значения вправо на одну десятичную цифру.
Нас интересуют строки 12–24. Эта работа осуществляется только на системе, поддерживающей локали, на что указывает наличие заголовочного файла
. Именованная константа HAVE_LOCALE
в такой системе будет равна true[143].
Когда условие в строке 13 истинно, настало время добавить символ разделителя тысяч. Это условие можно прочесть как «если требуется группировка и текущее положение в
loc.grouping
указывает нужное для группировки количество и текущее число цифр равно группируемому количеству». Если это условие истинно, строка 14 добавляет символ разделителя тысяч. Комментарий обращает внимание на предположение, которое, вероятно, истинно, но которое может вновь появиться позже. ('XXX' является традиционным способом выделения опасного или сомнительного кода. Его легко отыскать, и он весьма заметен для читателя кода.)
После использования текущего положения в
loc.grouping
строки 15–22 заглядывают в значение в следующем положении. Если это 0, продолжает использоваться значение текущего положения. Мы указываем на это, восстанавливая 0 в jj
(строка 16). С другой стороны, если в следующем положении CHAR_MAX
, группировка должна быть прекращена, и строка 18 убирает ее, устанавливая quote_flag
в false. В противном случае, следующее значение является значением группировки, поэтому строка 20 восстанавливает 0 в jj
, а строка 21 увеличивает значение ii
.
Это низкоуровневый, подробный код. Однако, поняв один раз, как представляется информация в
struct lconv
, код читать просто (и его было просто писать).
13.2.7. Форматирование значений даты и времени: ctime()
и strftime()
В разделе 6.1 «Времена и даты» описаны функции для получения и форматирования значений времени и даты. Функция
strftime()
также может использовать локаль, если setlocale()
была вызвана должным образом. Это демонстрирует следующая простая программа, ch13-times.с
:
/* ch13-times.c --- демонстрация времени на основе локали */
#include
#include
#include
int main(void) {
char buf[100];
time_t now;
struct tm *curtime;
setlocale(LC_ALL, "");
time(&now);
curtime = localtime(&now);
(void)strftime(buf, sizeof buf,
"It is now %A, %B %d, %Y, %I:%M %p", curtime);
printf("%s\n", buf);
printf("ctime() says: %s", ctime(&now));
exit(0);
}
При запуске программы мы видим, что результаты
strftime()
в самом деле варьируют, тогда как результаты ctime()
— нет:
$ LC_ALL=en_US ch13-times /* Время в Соединенных Штатах */
It is now Friday, July 11, 2003, 10:35 AM
ctime() says: Fri Jul 11 10:35:55 2003
$ LC_ALL=it_IT ch13-times /* Время в Италии */
It is now venerdi, luglio 11, 2003, 10:36
ctime() says: Fri Jul 11 10:36:00 2003
$ LC_ALL=fr_FR ch13-times /* Время во Франции */
It is now vendredi, juillet 11, 2003, 10:36
ctime() says: Fri Jul 11 10:36:05 2003
Причина отсутствия изменений в том, что
ctime()
(и asctime()
, на которой основана ctime()
) является традиционным интерфейсом; он существует для поддержки старого кода, strftime()
, будучи более новым интерфейсом (первоначально разработанным для C89), свободен использовать локали.
13.2.8. Другие данные локали: nl_langinfo()
Хотя ранее мы сказали, что API
catgets()
трудно использовать, одна часть этого API обычно полезна: nl_langinfo()
. Она предоставляет дополнительные связанные с локалью сведения, помимо тех, которые доступны из struct lconv
:
#include
#include
char *nl_langinfo(nl_item item);
Заголовочный файл
определяет тип nl_item
. (Это скорее всего int
или enum
.) Параметр item
является одной из именованных констант, определенных в
. Возвращаемое значение является строкой, которую можно при необходимости использовать либо непосредственно, либо в качестве форматирующей строки для strftime()
.
Доступная информация поступает из нескольких категорий локали. В табл. 13.3 перечислены константы элементов, соответствующие категории локали и их значения.
Таблица 13.3. Значения элементов для
nl_langinfo()
Элемент
Категория
Значение
ABDAY_1
, …, ABDAY_7
LC_TIME
Сокращенные названия дней недели. Воскресенье является днем 1
ABMON_1
, …, ABMON_12
LC_TIME
Сокращенные названия месяцев
ALT_DIGITS
LC_TIME
Альтернативные символы для цифр; см. текст
AM_STR
, PM_STR
LC_TIME
Обозначения a.m/p.m. для локали.
CODESET
LC_TYPE
Имя кодовой страницы для локали, т.е. использующиеся набор символов и кодировка
CRNCYSTR
LC_MONETARY
Символ местной валюты, описанный ниже
DAY_1
, …, DAY_7
LC_TIME
Названия дней недели. Воскресенье является днем 1
D_FMT
LC_TIME
Формат даты
D_T_FMT
LC_TIME
Формат даты и времени
ERA_D_FMT
LC_TIME
Формат даты эры.
ERA_D_T_FMT
LC_TIME
Формат даты и времени эры.
ERA_T_FMT
LC_TIME
Формат времени эры.
ERA
LC_TIME
Сегменты описания эры, см. текст.
MON_1
, …, MON_12
LC_TIME
Названия месяцев.
RADIXCHAR
LC_NUMERIC
Символ системы счисления. Для базы 10 это символ точки в десятичной дроби.
THOUSEP
LC_NUMERIC
Символ-разделитель тысяч
T_FMT_AMPM
LC_TIME
Формат времени в записи a.m/p.m.
T_FMT
LC_TIME
Формат времени.
YESEXPR
, NOEXPR
LC_MESSAGES
Строка, представляющая положительный и отрицательный ответы.
Эра является определенным временем в истории. Поскольку она имеет отношение к датам и временам, она имеет наибольший смысл в странах, управляемых императорами и династиями.[144]
Спецификации эр POSIX могут определять эры ранее 1 г. н.э. В таких случаях у начальной даты большее абсолютное числовое значение, чем у конечной даты. Например, Александр Великий правил с 336 г. до н.э. по 323 г до н.э.
Значение, возвращенное '
nl_langinfo(ERA)
', если оно не равно NULL
, состоит из одной или более спецификаций эр. Каждая спецификация отделена от следующей символом ';
'. Компоненты спецификации каждой эры отделяются друг от друга символом ':
'. Компоненты описаны в табл. 13.4.
Таблица 13.4. Компоненты спецификации эры
Компонент
Значение
Направление
Символы '+
' или '-
'. '+
' означает, что эра отсчитывается от численно меньшего года к численно большему году, а '-
' означает обратный порядок
Смешение
Ближайший к дате начала эры год
Дата начала
Дата начала эры в виде 'гггг/мм/дд'. Это соответственно год, месяц и день. Годы до н.э используют для гггг отрицательные значения
Дата конца
Дата завершения эры в том же самом виде. Допустимы два дополнительных вида: -*
означает «начало времени», а +*
означает «конец времени»
Название эры
Название эры, соответствующее спецификации преобразования %EC
функции strftime()
Формат эры
Формат года в пределах эры, соответствующий спецификации преобразования %EY
функции strftime()
Значение
ALT_DIGITS
также нуждается в некотором объяснении. Некоторые локали предоставляют «альтернативные цифры». (Рассмотрите арабский язык, в котором используется десятичная система счисления, но изображения для цифр 0–9 другие. Или рассмотрите гипотетическую локаль «Древнего Рима», использующую римские цифры.) Они появляются, например, в различных спецификациях преобразования %OC
в функции strftime()
. Возвращаемое значение для 'nl_langinfo(ALT_DIGITS)
' является разделяемым точками с запятой списком строк символов для альтернативных цифр. Первая должна использоваться для 0, следующая для 1 и т.д. POSIX утверждает, что могут быть предоставлены до 100 альтернативных символов. Сущность в том, чтобы избежать ограничения локалей использованием символов цифр ASCII, когда у локали есть собственная система счисления.
Наконец, '
nl_langinfo(CRNCYSTR)
' возвращает символ местной валюты. Первый символ возвращаемого значения, если это '-
', '+
' или '.
', указывает, как должен использоваться символ:
-
Символ должен быть перед значением.
+
Символ должен быть после значения.
.
Символ должен заменить символ основания (разделитель десятичной дроби).
13.3. Динамический перевод сообщений программ
Только что освещенные интерфейсы стандартной библиотеки С решают простые части проблемы локализации. Для денежных, числовых значений, значений времени и даты, также, как для проблем сортировки строк, применяется управление посредством таблиц специфичных для локали данных (таких, как списки названий месяцев и дней).
Однако, большая часть взаимодействия пользователя с текстовой программой осуществляется в виде выводимых сообщений, таких, как приглашения или сообщения об ошибках. Проблема заключается в необходимости избежания множества версий одной и той же программы, которые отличаются лишь содержанием строк сообщений. Решением де-факто в мире GNU является GNU
gettext
. (GNU программы сталкиваются с подобными проблемами с элементами меню; обычно у каждого большого инструментария пользовательского интерфейса свой способ решения этой проблемы.)
GNU
gettext
дает возможность перевода сообщений программы на другие языки во время исполнения. Внутри кода программы этот перевод включает несколько шагов, каждый из которых использует свои библиотечные функции. Когда сама программа должным образом подготовлена, несколько утилит на уровне оболочки дают возможность подготовить переводы на другие языки. Каждый такой перевод называется списком сообщений (message catalog).
13.3.1. Установка текстового домена: textdomain()
Законченное приложение может содержать множество компонентов: отдельные исполняемые файлы, написанные на С или C++ или на языках сценариев, которые также могут получить доступ к возможностям
gettext
, таких, как gawk
или оболочка Bash Все компоненты приложения разделяют один и тот же текстовый домен, который является строкой, уникально идентифицирующей приложение. (Примерами могут быть «gawk
» или «coreutils
»; первое является простой программой, а последнее — целым набором программ.) Текстовый домен устанавливается функцией textdomain()
:
#include /* GLIBC */
char* textdomain(const char *domainname)
Каждый компонент должен вызывать эту функцию со строкой, указывающей на текстовый домен, в составе первоначальной инициализации в
main()
. Возвращаемое значение является текущим текстовым доменом. Если аргумент domainname
равен NULL
, возвращается текущий домен; в противном случае, он устанавливается в указанное значение, а последнее возвращается. Возвращаемое значение NULL
указывает на какую-нибудь разновидность ошибки.
Если текстовый домен не установлен с помощью
textdomain()
, по умолчанию используется «messages
».
13.3.2. Перевод сообщений: gettext()
Следующим после установки текстового домена шагом является использование функции
gettext()
(или ее разновидности) для каждой строки, которая должна быть переведена. Несколько функций предоставляют службы перевода:
#include /* GLIBC */
char *gettext(const char *msgid);
char *dgettext(const char *domainname, const char *msgid);
char *dcgettext(const char *domainname, const char *msgid, int category);
Аргументы, используемые в этих функциях, следующие:
const char *msgid
Переводимая строка. Она действует в качестве ключа к базе данных переводов.
const char *domainname
Текстовый домен, из которого нужно получить перевод. Таким образом, хотя
main()
вызвала textdomain()
для установки собственного домена приложения, сообщения могут быть получены из других текстовых доменов. (Это наиболее применимо к сообщениям, которые могли бы быть, например, в текстовом домене библиотеки от третьей стороны.)
int category
Одна из описанных ранее категорий доменов (
LC_TIME
и т.п.). Доменом по умолчанию является то, что было раньше установлено с помощью textdomain()
(«messages
», если textdomain()
никогда не вызывалась). Категорией по умолчанию является LC_MESSAGES
. Предположим, main()
делает следующий вызов:
textdomain("killerapp");
Тогда '
gettext("my message")
' эквивалентно 'dgettext("killerapp", "my message")
'. Обе функции, в свою очередь, эквивалентны 'dcgettext("killerapp", "my message", LC_MESSAGES)
'.
В 99,9% времени бывает нужно использовать
gettext()
. Однако, другие функции обеспечивают гибкость при работе с другими текстовыми доменами или категориями локалей. Скорее всего, эта гибкость потребуется при программировании библиотек, поскольку автономная библиотека почти наверняка будет использовать свой собственный текстовый домен.
Все функции возвращают строки. Строка является либо переводом данного
msgid
, либо, если перевода не существует, первоначальной строкой. Таким образом, всегда имеется какой-нибудь вывод, даже если это первоначальное сообщение (предположительно на английском). Например:
/* Каноническая первая программа, локализованная версия. */
#include
#include
#include
int main(void) {
setlocale(LC_ALL, "");
printf("%s\n", gettext("hello, world"));
return 0;
}
Хотя сообщение является простой строкой, мы не используем ее непосредственно в форматирующей строке
printf()
, поскольку в общем перевод может содержать символы %
.
Вскоре, в разделе 13.3.4 «Упрощение использования
gettext()
», мы увидим, как облегчить использование gettext()
в крупномасштабных, реальных программах.
13.3.3. Работа с множественными числами: ngettext()
Перевод во множественном числе доставляет дополнительные трудности. Простой код мог бы выглядеть примерно так:
printf("%d word%s misspelled\n", nwords, nwords > 1 ? "s" : "");
/* или */
printf("%d %s misspelled\n", nwords, nwords == 1 ? "word" : "words").
Это подходит для английского языка, но перевод становится трудным. Во-первых, во многих языках множественное число не образуется с такой же легкостью, как в английском (добавлением суффикса
s
для большинства слов). Во-вторых, во многих языках, особенно в Восточной Европе, имеются несколько форм множественного числа, каждая из которых указывает на то, сколько объектов обозначает форма. Соответственно даже код наподобие следующего не будет достаточным:
if (nwords == l)
printf("one word misspelled\n");
else
printf("%d words misspelled\n", nwords);
Решением является параллельный набор процедур специально для форматирования множественных значений:
#include /* GLIBC */
char *ngettext(const char *msgid, const char *msgid_plural,
unsigned long int n);
char *dngettext(const char *domainname, const char *msgid,
const char *msgid_plural, unsigned long int n);
char *dcngettext(const char *domainname, const char *nmgid,
const char *msgid_plural, unsigned long int n,
int category)
Помимо первоначального аргумента
msgid
, эти функции принимают дополнительные аргументы:
const char *msgid_plural
Строка по умолчанию для использования в качестве множественного числа. Вскоре будут примеры.
unsigned long int n
Число имеющихся элементов.
Список сообщений каждой локали указывает, как переводить множественные числа.[145] Функция
ngettext()
(и ее варианты) проверяет n
и на основании спецификации в списке сообщений возвращает соответствующий перевод msgid
. Если в списке нет перевода для msgid
, или находясь в локали «С», ngettext()
возвращает msgid
, если 'n == 1
'; в противном случае она возвращает msgid_plural
. Таким образом, наш пример ошибочных слов выглядит следующим образом:
printf("%s\n", ngettext("%d word misspelled", "%d words misspelled", nwords), nwords);
Обратите внимание, что
nwords
должен быть передан ngettext()
для выбора форматирующей строки, а затем printf()
для форматирования. Вдобавок, будьте осмотрительны и не используйте макрос или выражение, значение которого каждый раз изменяется, как в случае 'n++
'! Такое может случиться, если вы осуществляете глобальное редактирование, добавляя вызовы ngettext()
и не обращая на это внимания.
13.3.4. Упрощение использования gettext()
Вызов
gettext()
в исходном коде программы служит двум целям. Во-первых, он осуществляет перевод во время исполнения, что является в конце концов главным. Однако, он служит также для отметки строк, которые нужно перевести. Утилита xgettext
читает исходный код программы и извлекает все оригинальные строки, которые нужно перевести. (Далее в главе мы кратко рассмотрим это.)
Рассмотрим все-таки случай, когда статические строки не используются непосредственно:
static char *copyrights[] = {
"Copyright 2004, Jane Programmer",
"Permission is granted ...",
/* ... Здесь куча легальностей */
NULL
};
void copyright(void) {
int i;
for (i = 0; copyrights[i] != NULL, i++)
printf("%s\n", gettext(copyrights[i]));
}
Здесь мы хотели бы иметь возможность вывести переводы строк об авторских правах, если они доступны. Однако, как извлекающее устройство
xgettext
предполагает найти эти строки? Мы не можем заключить их в вызовы gettext()
, поскольку это не будет работать во время компиляции:
/
* ПЛОХОЙ КОД: не будет компилироваться */
static char *copyrights[] = {
gettext("Copyright 2004, Jane Programmer"),
gettext("Permission is granted ..."),
/* ... Здесь куча легальностей */
NULL
};
13.3.4.1. Переносимые программы: "gettext.h
"
Здесь мы предполагаем, что вы хотите написать программу, которая может использоваться вместе с библиотекой GNU
gettext
на любой системе Unix, а не только GNU/Linux. Следующий раздел описывает, что сделать для программ только для GNU/Linux.
Пометка строк включает два шага. Первый заключается в использовании вспомогательного заголовка
gettext.h
, который поставляется с дистрибутивом GNU gettext
. Этот файл обрабатывает несколько проблем переносимости и компиляции, упрощая использование gettext()
в ваших собственных программах:
#define ENABLELNLS 1 /* ENABLE_NLS должен быть true, чтобы gettext() работала */
#include "gettext.h" /* Вместо */
Если макрос
ENABLE_NLS
не определен[146] или установлен в ноль, gettext.h
развертывает вызовы gettext()
в первый аргумент. Это делает возможным перенос кода, использующего gettext()
, на системы, в которых не установлены ни GNU gettext
, ни собственная их версия. Помимо прочего, этот заголовочный файл определяет следующий макрос:
/* Вызов псевдофункции, который служит в качестве маркера для
автоматического извлечения сообщений, но не осуществляющий вызов
gettext(). Перевод времени исполнения осуществляется в другом
месте кода. Аргумент String должен быть символической строкой.
Сцепленные строки и другие строковые выражения не будут работать.
Разворачивание макроса не параметризовано, так что он подходит для
инициализации статических переменных 'char[]' или 'const char[]'. */
#define gettext_noop(String) String
Комментарий самодостаточен. С помощью этого макроса мы можем теперь перейти ко второму шагу. Мы перепишем код следующим образом:
#define ENABLE_NLS 1
#include "gettext.h"
static char copyrights[] =
gettext_noop("Copyright 2004, Jane Programmer\n"
"Permission is granted ...\n"
/* ... Здесь куча легальностей */
"So there.");
void copyright(void) {
printf("%s\n", gettext(copyrights));
}
Обратите внимание, что мы сделали два изменения. Во-первых,
copyrights
теперь является одной длинной строкой, созданной с использованием возможности конкатенации строк стандартного C. Эта простая строка затем включена в вызов gettext_noop()
. Нам нужна одна строка, чтобы легальности могли быть переведены в виде одного элемента
Второе изменение заключается в непосредственном выводе перевода в виде одной строки в
copyright()
.
К этому времени вы, возможно, думаете: «Вот здорово, набирать каждый раз '
gettext(...)
' довольно неприятно». Ну, вы правы. Это не только создает лишнюю работу по набиванию, но также и затрудняет чтение исходного кода. Соответственно, когда вы используете заголовочный файл gettext.h
, руководство GNU gettext
рекомендует включить два других макроса с именами _()
и N_()
следующим образом:
#define ENABLE_NLS 1
#include "gettext.h"
#define _(msgid) gettext(msgid)
#define N_(msgid) msgid
Такой подход снижает накладные расходы по использованию
gettext()
всего лишь тремя дополнительными символами для переводимой строковой константы и всего лишь четырьмя символами для статических строк:
#include
#define ENABLE_NLS 1
#include "gettext.h"
#define _(msgid) gettext(msgid)
#define N_(msgid) msgid
...
static char copyrights[] =
N_("Copyright 2004, Jane Programmer\n"
"Permission is granted ...\n"
/* ... Здесь куча легальностей */
"So there.");
void copyright(void) {
printf("%s\n", gettext(copyrights));
}
int main(void) {
setlocale(LC_ALL, ""); /* gettext.h gets for us too */
printf("%s\n", _("hello, world"));
copyright();
exit(0);
}
Эти макросы скромны, и на практике все GNU программы, использующие GNU
gettext
, следуют этому соглашению. Если вы собираетесь использовать GNU gettext
, вам тоже нужно следовать этому соглашению.
13.3.4.2. Только GLIBC:
Для программ, которые будут использоваться лишь на системах с GLIBC, использование заголовочных файлов и макросов похоже, но проще:
#include
#include
#define _(msgid) gettext(msgid)
#define N_(msgid) msgid
/* ... все остальное то же ... */
Как мы видели ранее, заголовочный файл
объявляет gettext()
и другие функции. Вам все равно нужно определять _()
и N_()
, но не нужно беспокоиться о ENABLE_NLS
или включении с исходным кодом вашей программы файла gettext.h
.
13.3.5. Перестановка порядка слов с помощью printf()
Иногда при переводах порядок слов, естественный для английского языка, не подходит в других языках. Например, на английском прилагательные идут перед определяемыми существительными, а на многих других языках — после. Таким образом, следующий код представляет проблему:
char *animal_color, *animal;
if (...) {
animal_color = _("brown");
animal = _("cat");
} else if (...) {
...
} else {
...
}
printf(_("the %s %s looks at you enquiringly.\n"), animal_color, color);
Здесь форматирующая строка,
animal_color
и animal
неудачно включены в вызов gettext()
. Однако, после перевода утверждение будет неверным, поскольку порядок аргументов не может быть изменен во время исполнения.
Чтобы обойти это, версия семейства
printf()
POSIX (но не ISO С) допускает использовать в описателе формата указатель положения. Он принимает форму десятичного числа, за которым следует символ $
, сразу после начального символа %
. Например printf("%2$s, %1s\n", "world", "hello")
;
Указатель положения обозначает аргумент из списка, который следует использовать, отсчет начинается с 1 и не включает саму форматирующую строку. Этот пример выводит знаменитое сообщение '
hello, world
' в правильном порядке.
GLIBC и Solaris реализуют эту возможность. Поскольку это часть POSIX, если
printf()
вашего поставщика Unix не реализует ее, она вскоре должна появиться.
За указателем положения могут следовать любые обычные флаги
printf()
, указатели ширины полей и точности. Вот правила для использования указателей положения:
• Форма с указателем положения не может смешиваться с формой без нее. Другими словами, или каждый указатель формата включает указатель положения, или ни один его не включает. Конечно,
%%
может использоваться всегда.
• Если в форматирующей строке используется N-й аргумент, в этой строке должны использоваться также все аргументы до N. Соответственно, следующее неверно
printf("%3$s %1$s\n", "hello", "cruel", "world")
;
• Ссылка на определенный аргумент может быть сделана указателем положения несколько раз. Не позиционные спецификаторы формата всегда движутся через список аргументов последовательно.
Эта возможность не предназначена для непосредственного использования программистами приложений, она скорее для переводчиков. Например, перевод предыдущей форматирующей строки,
"The %s %s looks at you enquiringly.\n"
, на французский мог бы быть:
"Le %2$s %1$s te regarde d'un aire interrogateur.\n"
(Даже этот перевод не совершенен: артикль «Le» имеет род. Подготовка программы к переводу трудная задача!)
13.3.6. Тестирование переводов в персональном каталоге
Коллекция сообщений в программе называется списком сообщений (message catalog). Этот термин применяется также к каждому из переводов сообщений на другой язык. Когда программа установлена, каждый перевод также устанавливается в стандартное место, где
gettext()
может во время исполнения найти нужный перевод.
Может оказаться полезным разместить переводы не в стандартном, а в другом каталоге, особенно для тестирования программы. Особенно на больших системах, у обычного пользователя может не быть необходимых разрешений для установки файлов в системные каталоги. Функция
bindtextdomain()
дает gettext()
альтернативное место для поиска переводов:
#include /* GLIBC */
char *bindtextdomain(const char *domainname,
const char *dirname);
Полезные каталоги включают '
.
' для текущего каталога и /tmp
. Может оказаться удобным также получить каталог из переменной окружения, подобно этому:
char *td_dir;
setlocale(LC_ALL, "");
textdomain("killerapp");
if ((td_dir = getenv("KILLERAPP_TD_DIR")) != NULL)
bindtextdomain("killerapp", td_dir);
bindtextdomain()
должна быть вызвана до вызовов любой из функций из семейства gettext()
. Мы увидим пример ее использования в разделе 13.3.8 «Создание переводов»
13.3.7. Подготовка интернационализированных программ
К настоящему моменту мы рассмотрели все компоненты, из которых состоит интернационализированная программа. Данный раздел подводит итоги.
1. Включите в свое приложение заголовочный файл
gettext.h
, добавьте определения для макросов _()
и N_()
в заголовочный файл, который включается во все ваши исходные файлы на С. Не забудьте определить именованную константу ENABLE_NLS
.
2. Вызовите соответствующим образом
setlocale()
. Проще всего вызвать 'setlocale(LC_ALL, "")
', но иногда приложению может потребоваться быть более разборчивым в отношении используемых категорий локали.
3. Выберите для приложения текстовый домен и установите его с помощью
textdomain()
.
4. При тестировании свяжите текстовый домен с определенным каталогом при помощи
bindtextdomain()
.
5. Используйте соответствующим образом
strfmon()
, strftime()
и флаг '
. Если нужна другая информация о локали, используйте nl_langinfo()
, особенно в сочетании с strftime()
.
6. Пометьте все строки, которые должны быть переведены, соответствующими вызовами
_()
или N_()
.
Хотя некоторые не следует так помечать. Например, если вы используете
getopt_long()
(см. раздел 2.1.2 «Длинные опции GNU»), вы, вероятно, не захотите, чтобы имена длинных опций были помечены для перевода. Не требуют перевода и простые форматирующие строки наподобие "%d %d\n
", также как отладочные сообщения.
7. В нужных местах используйте
ngettext()
(или ее варианты) для значений, которые могут быть 1 или больше 1.
8. Упростите жизнь для своих переводчиков, используя строки с полными предложениями вместо замены слов с помощью
%s
и ?:
. Например:
if (/* возникла ошибка */) { /* ВЕРНО */
/* Использовать несколько строк для упрощения перевода. */
if (input_type == INPUT_FILE)
fprintf(stderr, _("%s: cannot read file: %s\n"),
argv[0], strerror(errno));
else
fprintf(stderr, _("%s: cannot read pipe: %s\n"),
argv[0], strerror(errno));
Это лучше, чем
if (/* возникла ошибка */) { /* НЕВЕРНО */
fprintf(stderr, _("%s: cannot read %s: %s\n"), argv[0],
input_type == INPUT_FILE ? _("file") : _("pipe"),
strerror(errno));
}
Как только что показано, хорошей мыслью является включение комментария, сообщающего о намеренном использовании нескольких строк, чтобы упростить перевод сообщений.
13.3.8. Создание переводов
После интернационализации программы необходимо подготовить переводы. Это осуществляется с помощью нескольких инструментов уровня оболочки. Мы начнем с интернационализированной версии
ch06-echodate.c
из раздела 6.1.4 «Преобразование разложенного времени в time_t
»:
/* ch13-echodate.c --- демонстрация переводов */
#include
#include
#include
#define ENABLE_NLS 1
#include "gettext.h"
#define _(msgid) gettext(msgid)
#define N_(msgid) msgid
int main (void) {
struct tm tm;
time_t then;
setlocale(LC_ALL, "");
bindtextdomain("echodate", ".");
textdomain("echodate");
printf("%s", _("Enter a Date/time as YYYY/MM/DD HH:MM:SS : "));
scanf("%d/%d/%d %d:%d:%d",
&tm.tm_year, &tm.tm_mon, &tm.tm_mday,
&tm.tm_hour, &tm.tm_min, &tm.tm_sec);
/* Проверка ошибок для краткости опущена. */
tm.tm_year -= 1900;
tm.tm_mon -= 1;
tm.tm_isdst = -1; /* О летнем времени ничего не известно */
then = mktime(&tm);
printf(_("Got: %s"), ctime(&then));
exit(0);
}
Мы намеренно использовали
"gettext.h"
, а не
. Если наше приложение поставляется с отдельной копией библиотеки gettext
, тогда "gettext.h"
найдет ее, избежав использования системной копии. С другой стороны, если имеется лишь системная копия, она будет найдена, если локальной копии нет. Общеизвестно, что ситуация усложнена фактом наличия на системах Solaris библиотеки gettext
, которая не имеет всех возможностей версии GNU.
Переходя к созданию переводов, первым шагом является извлечение переводимых строк. Это осуществляется программой
xgettext
:
$ xgettext --keyword=_ --keyword=N_ \
> --default-domain=echodate ch13-echodate.с
Опции
--keyword
сообщает xgettext
, что нужно искать макросы _()
и N_()
. Программа уже знает, как извлекать строки из gettext()
и ее вариантов, а также из gettext_noop()
.
Вывод
xgettext
называется переносимым объектным файлом. Имя файла по умолчанию messages.ро
, что соответствует текстовому домену по умолчанию "messages"
. Опция --default-domain
обозначает текстовый домен для использования в имени выходного файла. В данном случае, файл назван echodate.ро
. Вот его содержание:
# SOME DESCRIPTIVE TITLE. /* Шаблон, нужно отредактировать */
# Copyright (С) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR , YEAR.
#
#, fuzzy
msgid "" /* Подробная информация */
msgstr "" /* Заполняет каждый переводчик */
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2003-07-14 18:46-0700\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME \n"
"Language-Team: LANGUAGE \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=CHARSET\n"
"Content-Transfer-Encoding: 8bit\n"
#: ch13-echodate.c:19 /* Местоположение сообщения */
msgid "Enter a Date/time as YYYY/MM/DD HH:MM:SS : " /* Оригинальное
сообщение */
msgstr "" /* Здесь перевод */
#: ch13-echodate.с:32 /* To же самое для каждого сообщения */
#, с-format
msgid "Got: %s"
msgstr ""
Этот первоначальный файл используется повторно для каждого перевода. Таким образом, это шаблон для переводов, и по соглашению, для отображения этого факта он должен быть переименован с расширением
.pot
(portable object template — переносимый объектный шаблон):
$ mv echodate.ро echodate.pot
He владея свободно несколькими языками, мы решили перевести сообщения на свинский латинский. Следующим шагом является создание перевода. Это осуществляется копированием файла шаблона и добавлением к новой копии перевода:
$ cp echodate.pot piglat.po
$ vi piglat.po /* Добавить переводы, используя любимый редактор */
Имя по соглашению должно быть
язык.po
, где язык
является стандартным международным сокращением из двух или трех букв для обозначения языка. Иногда используется форма язык_страна.po
: например, pt_BR.po
для португальского в Бразилии. Поскольку свинский латинский не является настоящим языком, мы назвали файл piglat.ро
.[147] Вот содержание после добавления перевода:
# echodate translations into pig Latin
# Copyright (C) 2004 Prentice-Hall
# This file is distributed under the same license as the echodate package.
# Arnold Robbins 2004
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: echodate 1.0\n"
"Report-Msgid-Bugs-To: arnold@example.com\n"
"POT-Creation-Date: 2003-07-14 18:46-0700\n"
"PO-Revision-Date: 2003-07-14 19:00+8\n"
"Last-Translator: Arnold Robbins \n"
"Language-Team: Pig Latin \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=ASCII\n"
"Content-Transfer-Encoding: 8bit\n"
#: ch13-echodate.с:19
msgid "Enter a Date/time as YYYY/MM/DD HH:MM:SS : "
msgstr "Enteray A Ateday/imetay asay YYYY/MM/DD HH:MM:SS : "
#: ch13-echodate.c:32
#, c-format
msgid "Got: %s"
msgstr "Otgay: %s"
Хотя можно было бы произвести линейный поиск в переносимом объектном файле, такой поиск был бы медленным. Например, в
gawk
имеется примерно 350 отдельных сообщений, а в GNU Coreutils — свыше 670. Линейный поиск в файле с сотнями сообщений был бы заметно медленным. Поэтому GNU gettext
использует для быстрого поиска сообщений двоичный формат. Сравнение осуществляет msgfmt
, выдавая объектный файл сообщений:
$ msgfmt piglat.po -о piglat.mo
При сопровождении программы изменяются строки, используемые программой: добавляются новые, другие удаляются или изменяются. По крайней мере, может измениться положение строки в исходном файле. Таким образом, файлы переводов
.ро
, вероятно, устареют. Программа msgmerge
объединяет старые файлы переводов с новым файлом .pot
. Затем результат может быть обновлен. Этот пример выполняет объединение и повторное компилирование:
$ msgmerge piglat.po echodate.pot -o piglat.new.po /* Объединить файлы */
$ mv piglat.new.po piglat.po /* Переименовать результат */
$ vi piglat.po /* Модернизировать перевод */
$ msgfmt piglat.po -o piglat.mo /* Восстановить файл .mo */
Откомпилированные файлы
.mo
помещаются в файл base/locale/category/textdomain.mo
. На системах GNU/Linux base
является /usr/share/locale
. locale
является обозначением языка, например, 'es
', 'fr
' и т.д. category
является категорией локали; для сообщений это LC_MESSAGES
. textdomain
является текстовым доменом программы, в нашем случае это echodate
. В качестве реального примера в /usr/share/locale/es/LC_MESSAGES/coreutils.mo
находится перевод GNU Coreutils на испанский.
Функция
bindtextdomain()
изменяет в местоположении часть base
. В ch13-echodate.c
мы меняем ее на '.
'. Таким образом, нужно создать соответствующие каталоги и поместить туда перевод на свинский латинский:
$ mkdir -р en_US/LC_MESSAGES /* Нужно использовать реальную локаль */
$ cp piglat.mo en_US/LC_MESSAGES/echodate.mo /* Поместить файл в нужное место */
Должна использоваться реальная локаль[148]; мы «притворяемся» использующими "
en_US
". Разместив перевод, устанавливаем соответствующим образом LC_ALL
, скрещиваем пальцы и запускаем программу:
$ LC_ALL=en_US ch13-echodate /* Запуск программы */
Enteray A Ateday/imetay asay YYYY/MM/DD HH:MM:SS : 2003/07/14 21:19:26
Otgay: Mon Jul 14 21:19:26 2003
Последнюю версию GNU
gettext
можно найти в каталоге дистрибутива GNU gettext
.[149]
Этот раздел лишь слегка коснулся поверхности процесса локализации. GNU
gettext
предоставляет множество инструментов для работы с переводами, и в особенности для облегчения поддержания современности переводов по мере развития исходного кода программы. Процесс ручного обновления переводов осуществим, но утомителен. Эта задача легко автоматизируется с помощью make
; в частности, GNU gettext
хорошо интегрируется для обеспечения этой возможности с Autoconf и Automake, снимая с программиста значительный груз по разработке.
Рекомендуем прочесть документацию GNU
gettext
, чтобы больше узнать как об этих проблемах в частности, так и о GNU gettext
в общем.
13.4. Не могли бы вы произнести это для меня по буквам?
В самые ранние дни вычислительной техники различные системы назначали различные соответствия между числовыми значениями и глифами (glyphs) — символами, такими, как буквы, цифры и знаки пунктуации, используемыми для общения с людьми. В конечном счете появились два широко использующихся стандарта: кодировка EBCDIC, используемая IBM и подобными ей мэйнфреймами, и ASCII, использующаяся для всего остального. Сегодня, за исключением мэйнфреймов, ASCII является основой для всех других использующихся наборов символов.
Оригинальный семиразрядный набор символов ASCII достаточен для американского английского и большинства знаков пунктуации и специальных символов (таких, как
$
, но нет символа для «цента»). Однако, имеется много языков и много стран, которым нужны другие наборы символов. ASCII не оперирует версиями романских символов с надстрочными значками, использующимися в Европе, а во многих азиатских языках тысячи символов. Для устранения этих недостатков были разработаны новые технологии.
Литература по интернационализации изобилует ссылками на три фундаментальных термина. Определив их и взаимоотношения между ними, мы сможем представить общее описание соответствующих функций API С.
Набор символов (character set)
Определение значений, присваиваемых различным целым величинам; например того, что A равно 65. Любой набор символов, использующий более восьми битов на символ, называется многобайтным набором символов.
Представление набора символов (character set encoding)
ASCII использует для представления символов один байт. Таким образом, целое значение хранится само по себе, непосредственно в дисковых файлах. Более современные наборы символов, особенно различные версии Unicode[150], используют для представления символов 16-разрядные или даже 32-разрядные целые значения. Для большинства определенных символов один, два или даже три старших байта целого значения равны нулю, что делает непосредственное хранение таких значений на диске неэффективным. Представление набора символов описывает механизм для преобразования 16- или 32-разрядных значений в последовательности от одного до шести байтов для сохранения на диске таким образом, что в целом наблюдается значительная экономия дисковой памяти.
Язык
Правила данного языка определяют использование набора символов. В частности, правила влияют на сортировку символов. Например, на французском е, é и è все должны находиться между d и f, независимо от назначенных этим символам числовых значений. Различные языки могут назначить (и назначают) одним и тем же глифам различный порядок сортировки.
Со временем для поддержки многобайтных наборов символов были разработаны различные технологии. Вычислительная практика медленно стремится к Unicode и соответствующим его представлениям, но стандартный С и POSIX поддерживают как старые, так и современные технологии. В данном разделе представлен концептуальный обзор различных возможностей. Нам самим не приходилось их использовать, поэтому мы предпочитаем просто познакомить с ними и предоставить ссылки на дополнительную информацию.
13.4.1. Широкие символы
Мы начнем с концепции широких символов (wide character). Широкий символ является целым типом, в котором может храниться любое значение из определенного используемого многобайтного набора символов.
Широкие символы представлены на С типом
wchar_t
. C99 предоставляет соответствующий тип wint_t
, в котором может находиться любое значение, допустимое для wchar_t
, а также специальное значение WEOF
, аналогичное обычному EOF
из
. В заголовочном файле
> определены различные типы. Ряд функций, сходных с функциями в
, такие, как iswalnum()
и др., определены в заголовочном файле
.
Широкие символы могут быть от 16 до 32 битов размером в зависимости от реализации. Как упоминалось, они нацелены на манипулирование данными в памяти и обычно не хранятся в файлах непосредственно.
Стандарт C предусматривает для широких символов большое число функций и макросов, соответствующих традиционным функциям, работающим с данными
char
. Например, wprintf()
, iswlower()
и т.д. Они документированы в справочных страницах GNU/Linux и в книгах по стандартному С.
13.4.2. Представления многобайтных символов
Строки широких символов сохраняются на диске путем преобразования их в памяти в многобайтное представление набора символов с последующей записью в дисковый файл. Сходным образом, такие строки считываются с диска через низкоуровневый блочный ввод/вывод, а затем конвертируются в памяти из многобайтной версии в версию широких символов.
Многие описанные кодировки используют для представления многобайтных символов состояния регистра (shift states). Другими словами, в данном потоке байтов значения байтов представляют самих себя до тех пор, пока не встретится специальное управляющее значение. В этот момент интерпретация изменяется в соответствии с текущим состоянием регистра. Таким образом, одно и то же восьмибитовое значение может иметь два значения: одно для обычного состояния, без использования регистра, и другое для использования регистра. Предполагается, что правильно закодированные строки начинаются и заканчиваются с одним и тем же состоянием регистра.
Значительным преимуществом Unicode является то, что его представления являются самокорректирующимися; кодировки не используют состояния регистров, поэтому потеря данных в середине не может повредить последующим закодированным данным.
Первоначальные версии функций преобразования многобайтных символов в широкие и широких в многобайтные поддерживали закрытую копию состояния преобразования (например, состояние регистра, а также все остальное, что могло понадобиться) Такая модель ограничивает использование функции лишь одним видом преобразования в течение жизни программы. Примерами являются
mblen()
(определение длины многобайтной строки), mbtowc()
(преобразование многобайтного символа в широкий), wctomb()
(преобразование широкого символа в многобайтный), mbstowcs()
(преобразование многобайтной строки в строку широких символов), wcstombs()
(преобразование строки широких символов в многобайтную строку).
Новые версии этих процедур называются повторно запускаемыми (restartable). Это означает, что код уровня пользователя сохраняет состояние преобразования в отдельном объекте типа
mbstate_t
. Соответствующими примерами являются mbrlen()
, mbrtowc()
, wcrtomb()
, mbsrtowcs()
и wcsrtombs()
. (Обратите внимание на r
в их именах, это означает «restartable».)
13.4.3. Языки
Языковые проблемы управляются локалью. Ранее в главе мы уже видели
setlocale()
POSIX предоставляет продуманный механизм для определения правил, посредством которых работает локаль; некоторые подробности см. в справочной странице GNU/Linux locale(5), а полностью — в самом стандарте POSIX.
Правда в том, что подробности на самом деле не нужны. Вам, как разработчику программ, не нужно беспокоиться о них; как заставить все работать, зависит от разработчиков библиотек. Все, что нужно, это понять концепции и использовать в своем коде соответствующие функции, такие, как
strcoll()
(см. раздел 13.2.3 «Сравнение строк: strcoll()
и strxfrm()
»).
Современные системы GLIBC предоставляют отличную поддержку локалей, включая поддерживающие локали процедуры сопоставления регулярных выражений. Например, расширенное регулярное выражение POSIX
[[:alpha:]][[:alnum:]]+
соответствует букве, за которой следуют одна или более букв или цифр (алфавитный символ, за которым следуют один или более алфавитно-цифровых символов). Определение того, какие символы соответствуют этим классам, зависит от локали. Например, это регулярное выражение соответствовало бы двум символам 'eè
', тогда как регулярное выражение [a-zA-Z][a-A-Zz0-9]+
традиционного, ориентированного на ASCII Unix — скорее всего нет. Классы символов POSIX перечислены в табл. 13.5.
Таблица 13.5. Классы символов регулярных выражений POSIX
Класс
Соответствует
[:alnum:]
Алфавитно-цифровые символы
[:alpha:]
Алфавитные символы
[:blank:]
Символы пробела и табуляции.
[:cntrl:]
Управляющие символы
[:digit:]
Цифровые символы
[:graph:]
Символы, являющиеся одновременно печатными и видимыми. (Символ конца строки печатный, но не видимый, тогда как $
является и тем, и другим.)
[:lower:]
Строчные алфавитные символы
[:print:]
Печатные (не управляющие) символы
[:punct:]
Знаки пунктуации (не буквы, цифры, управляющие или пробельные символы)
[:space:]
Пробельные символы (такие, как сам пробел, символы табуляции, конца строки и т.д)
[:upper:]
Заглавные алфавитные символы
[:xdigit:]
Символы из набора abcdefABCDEF0123456789
13.4.4. Заключение
Возможно, вам никогда не придется иметь дело с различными наборами символов и их представлениями. С другой стороны, мир быстро становится «глобальным сообществом», и авторы программ не могут позволить себе быть ограниченными. Следовательно, стоит знать о проблемах интернационализации и наборов символов, а также способах их влияния на поведение вашей системы. По крайней мере, уже один из поставщиков дистрибутивов GNU/Linux устанавливает для систем в Соединенных Штатах локаль по умолчанию
en_US.UTF-8
.
13.5. Рекомендуемая литература
1. С, A Reference Manual, 5th edition, by Samuel P. Harbison III and Guy L. Steele, Jr., Prentice-Hall, Upper Saddle River, New Jersey, USA, 2002. ISBN: 0-13-089592-X.
Мы уже упоминали эту книгу раньше. Она дает точное и исчерпывающее описание развития и использования возможностей стандартной библиотеки С для работы с многобайтными и широкими символами. Это особенно ценно для современных систем, поддерживающих C99, поскольку библиотека была значительно усовершенствована для стандарта С 1999 г.
2. GNU gettext tools, by Ulrich Drepper, Jim Meyering, François Pinard, and Bruno Haible. Это руководство по GNU
gettext
. На системе GNU/Linux вы можете посмотреть локальную копию через 'info gettext
'. Или загрузить и распечатать последнюю версию (по адресу ftp://ftp.gnu.org/gnu/gettext/
).
13.6. Резюме
• Интернационализация и локализация программ подпадают под общее название поддержки родного языка. Широко распространенными сокращениями являются i18n, l10n и NLS. Центральным является понятие локали, которая позволяет настраивать набор символов, отображение даты, времени, денежных и числовых величин в соответствии с принятыми для данного языка и в данной стране нормами.
• Использование локали устанавливается с помощью функции
setlocale()
. Различные категории локали предоставляют доступ к различным видам информации локали. Не использующие локаль программы действуют, как если бы они находились в локали «С», которая выдает типичные для систем Unix до NLS результаты: 7-разрядный ASCII, английские названия месяцев и дней и т.д. Локаль «POSIX» эквивалентна локали «С».
• Сравнение строк с учетом локали осуществляется функцией
strcoll()
или комбинацией strxfrm()
и strcmp()
. Возможности библиотеки предоставляют доступ к сведениям о локали (localeconv()
и nl_langinfo()
), а также к специфического для локали форматирования (strfmon()
, strftime()
и printf()
).
• Обратной стороной получения относящейся к локали информации является вывод сообщений на местном языке. Модель
catgets()
System V, хотя и стандартизована POSIX, трудна для использования и поэтому не рекомендуется.[151] Вместо этого GNU gettext
реализует и расширяет оригинальный замысел Solaris.
• При использовании
gettext()
оригинальная строка сообщения на английском действует в качестве ключа в двоичном файле перевода, из которого получается перевод строки. Каждое приложение указывает уникальный текстовый домен таким образом, чтобы gettext()
могла найти нужный файл с переводом (известный как «список сообщений»). Текстовый домен устанавливается с помощью функции textdomain()
. При тестировании или иной надобности местоположение списка сообщений можно изменить с помощью функции bindtextdomain()
.
•
gettext()
и ее варианты предоставляют доступ к переводам в различных текстовых доменах или различных категориях локалей. Вдобавок, функция ngettext()
и ее варианты дают возможность делать правильные переводы множественных чисел, не перегружая разработчика. Указатель положения в спецификаторе формата printf()
дает возможность перевода форматирующих строк, аргументы которых должны выводиться в другом порядке, чем они располагаются в строке.
• На практике GNU программы используют для пометки переводимых строк в исходных файлах заголовочный файл
gettext.h
и макросы _()
и N_()
. Такая практика обеспечивает удобочитаемость исходного кода и возможность его поддержки, предоставляя в то же время преимущества интернационализации и локализации.
• GNU
gettext
предоставляет многочисленные инструменты для создания и управления базами данных переводов (переносимых объектных файлов) и их двоичными эквивалентами (объектными файлами сообщений).
• Наконец, стоит быть в курсе проблем наборов символов и их представлений. Поставщики программного обеспечения не могут больше позволить себе предполагать, что их пользователи хотят работать лишь на одном языке.
Упражнения
1. Поддерживает ли ваша система локали? Если да, какая локаль используется по умолчанию?
2. Просмотрите справочную страницу locale(1), если она у вас есть. Сколько имеется локалей, если вы посчитаете их с помощью '
locale -a | wc -l
'?
3. Поэкспериментируйте с
ch13-strings.с
, ch13-lconv.c
, ch13-strfmon.с
, ch13-quoteflag.c
и ch13-times.c
в различных локалях. Какая из найденных локалей самая «необычная» и почему?
4. Возьмите одну из своих программ. Интернационализируйте ее с использованием GNU
gettext
. Постарайтесь найти кого-нибудь, кто говорит на другом языке, чтобы перевести для вас сообщения. Откомпилируйте перевод и протестируйте его, использовав bindtextdomain()
. Какова была реакция вашего переводчика при виде использования перевода?
Ранние вычислительные системы обычно для своего вывода (приглашений, сообщений об ошибках) и ввода (ответы на запросы, такие, как «да» и «нет») использовали английский язык. Это было верно для систем Unix вплоть до середины 1980-х. В конце 80-х, начиная с первого стандарта ISO для С и продолжая стандартами POSIX 1990-х и современным стандартом POSIX, были разработаны возможности для работы программ на нескольких языках без необходимости поддержки нескольких версий одной и той же программы. Данная глава описывает, как современные программы должны справляться с многоязычными проблемами.
13.1. Введение
Центральной концепцией является окружение, место, в котором работает программа. Локали содержат в себе следующие сведения: локальный набор символов; сведения о формате отображения даты и времени; форматирование и отображение денежных сумм; форматирование и отображение числовых значений (с или без разделителей тысяч, какой символ используется в качестве разделителя дробной части числа и т.д.).
Интернационализация является процессом написания (или изменения) программы таким образом, что она может работать с различными локалями. Локализация является процессом приспособления интернационализированной программы для определенной локали. Часто вместо этих терминов используют сокращения i18n и l10n соответственно. (Числовое значение указывает, сколько букв в середине слова, а эти сокращения имеют небольшое сходство с полными терминами.[136] Их также гораздо легче набирать.) Другим часто встречающимся термином является поддержка родного языка, обозначаемая как NLS[137]; NLS обозначает программную поддержку для i18n и l10n.
Кроме того, некоторые люди используют термин глобализация (сокращенно g10n) для обозначения процесса подготовки всех возможных локализаций для интернационализированной программы. Другими словами, подготовки программы для глобального использования.
Возможности NLS существуют на двух уровнях. Первым уровнем является библиотека С. Она предоставляет сведения о локали; процедуры для обработки большей части низкоуровневых подробностей работы по форматированию даты/времени, числовых и денежных значений; и процедуры для корректного для данной локали сопоставления регулярных выражений и классификации символов и сравнений. Именно возможности библиотеки появляются в стандартах С и POSIX.
На уровне приложения GNU
gettextgettextgettextgettextВ дополнение к локалям и
gettext13.2. Локали и библиотека С
Специфичное для локали поведение управляется посредством установки переменных окружения, описывающих, какую локаль (локали) использовать для той или иной информации. Число доступных локалей, предлагаемых каждой конкретной операционной системой, колеблется от менее чем десяти на некоторых коммерческих системах Unix до сотен локалей на системах GNU/Linux. ('
locale -aГарантируется существование двух локалей, «С» и «POSIX». Они действуют в качестве локали по умолчанию, предоставляя окружение 7-разрядного ASCII, поведение которого такое же, как на традиционных системах Unix без поддержки локалей. В противном случае, локали обозначают язык, страну, а также могут включать сведения о наборе символов. Например, '
it_ITit_IT.UTF-8Дополнительные подробности об именах локалей можно найти в справочной странице GNU/Linux setlocale(3). Обычно дистрибутивы GNU/Linux устанавливают для системы локаль по умолчанию при ее установке, основываясь на языке, выбранном тем кто устанавливал ее, и пользователям больше не приходится об этом беспокоиться.
13.2.1. Категории локалей и переменные окружения
Заголовочный файл
Таблица 13.1. Константы категорий локалей ISO С, определенные в
| Категория | Значение |
|---|---|
|
Эта категория включает всю возможную информацию локали. Она состоит из оставшейся части элементов этой таблицы |
|
Категория для сравнения строк (обсуждаемого ниже) и областей регулярных выражений |
|
Категория для классификации символов (заглавные, строчные и т.д.) Это влияет на сопоставление регулярных выражений и функции |
|
Категория для специфичных для локали сообщений. Эта категория вступает в игру с GNU |
|
Категория для форматирования денежной информации, такой, как локальные и международные символы для местной валюты (например, $ против USD для доллара США), форматирования отрицательных величин и т.д. |
|
Категория для форматирования числовых значений |
|
Категория для форматирования дат и времени |
Эти категории определены различными стандартами. Некоторые системы могут поддерживать дополнительные категории, такие, как
LC_TELEPHONELC_ADDRESS#ifdefПо умолчанию, программы С и библиотека С ведут себя так, как если бы они находились в локали «С» или «POSIX» для обеспечения обратной совместимости со старыми системами. Однако, вызвав
setlocale()Переменные окружения имеют те же самые имена, что и перечисленные в табл. 13.1 категории локалей. Таким образом, команда —
export LC_NUMERIС=en_DK LC_TIME=C— определяет, что числа должны выводиться в соответствии с локалью '
en_DKСПеременная окружения
LC_ALLLC_xxxLC_ALLLC_CTYPELC_MONETARYLANGgawk$ unset LC_ALL LANG /* Удалить переменные по умолчанию */$ export LС_NUMERIC=en_DK LC_TIME=C /* Европейские числа, дата и время по умолчанию */$ gawk 'BEGIN { print 1.234 ; print strftime() }' /* Вывести число, текущие дату и время */1,234Wed Jul 09 09:32:18 PDT 2003$ export LC_NUMERIC=it_IT LC_TIME=it_IT /* Итальянские числа, дата и время */$ gawk 'BEGIN { print 1.234 ; print strftime() }' /* Вывести число, текущие дату и время */1,234mer lug 09 09:32:40 PDT 2003$ export LC_ALL=C /* Установить перекрывающую переменную */$ gawk 'BEGIN { print 1.234 ; print strftime() }' /* Вывести число, текущие дату и время */1.234Wed Jul 09 09:33:00 PDT 2003Для
awk.Почти все GNU версии стандартных утилит Unix могут использовать локали. Таким образом, особенно на системах GNU/Linux, установка этих переменных позволяет вам контролировать поведение системы[139].
13.2.2. Установка локали: setlocale()
setlocale()Как уже упоминалось, если вы ничего не делаете, программы на С и библиотека С ведет себя так, как если бы использовалась локаль «С». Функция
setlocale()#include /* ISO С */ char *setlocale(int category, const char *locale);Аргумент
categorylocalelocale""setlocale()Если
localeNULLПоскольку каждая категория может быть установлена индивидуально, автор приложения решает, насколько будет программа использовать локаль. Например, если
main()setlocale(LC_TIME, ""); /* Использование локали только для времени и все */— тогда, независимо от установленных в окружении других переменных
LC_xxxsetlocale(LC_TIME, "it_IT"); /* Время всегда итальянское */заменяет переменную окружения
LC_TIMELC_ALL""setlocale()Можно индивидуально вызывать
setlocale()/* Находясь в Риме, вместо «всего» делайте все как римляне. :-) */setlocale(LC_ALL, "");Возвращаемое
setlocale()setlocale()char *initial_locale;initial_locale = strdup(setlocale(LC_ALL, "")); /* сохранить копию */...(void)setlocale(LC_ALL, initial_locale); /* восстановить ее */Здесь мы сохранили копию, использовав функцию POSIX
strdup()strdup()
13.2.3. Сравнение строк: strcoll()
и strxfrm
()
strcoll()strxfrmЗнакомая функция
strcmp()strcmp()Однако, при наличии локалей простого числового сравнения недостаточно. Каждая локаль определяет для содержащихся в ней символов последовательность сортировки, другими словами, относительный порядок символов внутри локали. Например, в простом 7-битном ASCII у двух символов '
Ааint i = strcmp("А", "a");ien_US.UTF-8Aastrcmp()Функция
strcoll()#include /* ISO С */ int strcoll(const char *s1, const char *s2);Она возвращает такие же отрицательные/нулевые/положительные значения, что и
strcmp()ch13-compare.c1 /* ch13-compare.с --- демонстрация strcmp() против strcoll() */23 #include 4 #include 5 #include 67 int main(void)8 {9 #define STRBUFSIZE 102410 char locale[STRBUFSIZE], curloc[STRBUFSIZE];11 char left[STRBUFSIZE], right[STRBUFSIZE];12 char buf[BUFSIZ];13 int count;1415 setlocale(LC_ALL, ""); /* установить локаль */16 strcpy(curloc, setlocale(LC_ALL, NULL)); /* сохранить ее */1718 printf("--> "); fflush(stdout);19 while (fgets(buf, sizeof buf, stdin) != NULL) {20 locale[0] = '\0';21 count = sscanf(buf, "%s %s %s", left, right, locale);22 if (count < 2)23 break;2425 if (*locale) {26 setlocale(LC_ALL, locale);27 strcpy(curloc, locale);28 }2930 printf("%s: strcmp(\"%s\", \"%s\") is %d\n", curloc, left,31 right, strcmp(left, right));32 printf("%s: strcoll(\"%s\", \"%s\") is %d\n", curloc, left,33 right, strcoll(left, right));3435 printf("\n--> "); fflush(stdout);36 }3738 exit(0);39 }Программа читает входные строки, состоящие из двух сравниваемых слов и необязательной локали, использующейся для сравнения. Если локаль дана, она становится локалью для последующих элементов. Программа начинает с любой локалью, которая установлена в окружении.
Массив
curlocleftrightlocaleСтроки 25–28 устанавливают новую локаль, если она приведена. Строки 30–33 выводят результаты сравнения, а строка 35 приглашает для дальнейшего ввода. Вот демонстрация:
$ ch13-compare /* Запуск программы */--> ABC abc /* Ввести два слова */С: strcmp("ABC", "abc") is -1 /* Программа началась в локали "С" */С: strcoll("ABC", "abc") is -1 /* В локали "С" идентичные рез-ты */--> ABC abc en_US /* Слова те же, локаль "en_US" */en_US: strcmp("ABC", "abc") is -1 /* strcmp() без изменений */en_US: strcoll("ABC", "abc") is 2 /* рез-ты strcoll() изменились' */--> ABC abc en_US.UTF-8 /* Слова те же, локаль "en_US.UTF-8" */en_US.UTF-8: strcmp("ABC", "abc") is -1en_US. UTF-8: strcoll("ABC", "abc") is 6 /* Другое значение, все еще положительное */--> junk JUNK /* Новые слова */en_US.UTF-8: strcmp("junk", "JUNK") is 1 /* предыдущая локаль */en_US.UTF-8: strcoll("junk", "JUNK") is -6Эта программа ясно показывает различие между
strcmp()strcoll()strcmp()strcoll()en_USЗАМЕЧАНИЕ. Специфическая для локали сортировка строк является проблемой также и для сопоставления регулярных выражений. Регулярные выражения допускают диапазоны символов внутри выражений со скобками, такие, как '
[a-z]["-/]Для локалей, не являющихся ASCII, такие диапазоны как '
[a-z]["-/]en_US.UTF-8Долговременным наиболее переносимым решением является использование классов символов POSIX, таких, как '
[[:lower:]][[:punct:]]Основанная на локалях сортировка потенциально дорогостоящая. Если вы ожидаете большого числа сравнений, где по крайней мере одна из строк не будет изменяться или где значения строк будут сравниваться друг с другом по несколько раз (как при сортировке списка), следует рассмотреть использование функции
strxfrm()strcmp()strxfrm()#include /* ISO С */ size_t strxfrm(char *dest, const char *src, size_t n);Идея в том, что
strxfrm()srcdestdestСтандарт POSIX явным образом разрешает устанавливать в
ndest NULLstrxfrm()src\0malloc()destsrcstrxfrm()#define STRBUFSIZE ...char s1[STRBUFSIZE], s2[STRBUFSIZE]; /* Оригинальные строки */char s1x[STRBUFSIZE], s2x[STRBUFSIZE]; /* Преобразованные копии */size_t len1, len2;int cmp;/* ... заполнить s1 и s2 ... */len1 = strlen(s1);len2 = strlen(s2);if (strxfrm(s1x, s1, len1) >= STRBUFSIZE || strxfrm(s2x, s2, len2) >= STRBUFSIZE) /* слишком большой, восстановить */cmp = strcmp(s1x, s2x);if (cmp == 0) /* равны */else if (cmp < 0) /* s1 < s2 */else /* s1 > s2 */Для одноразовых сравнений, возможно, быстрее непосредственно использовать
strcoll()strxfrm()strcmp()strncmp()strcasecmp()
13.2.4. Числовое и денежное низкоуровневое форматирование: localeconv()
localeconv()Корректное форматирование числовых и денежных значений требует значительной низкоуровневой информации. Указанная информация доступна в
struct lconvlocaleconv()#include /* ISO С */ struct lconv *localeconv(void);Подобно функции
ctime()struct lconvstruct lconv { /* Числовая (не денежная) информация. */ char *decimal_point; /* Разделитель десятичной дроби. */ char *thousands_sep; /* Разделитель тысяч. */ /* Каждый элемент является числом цифр в каждой группе; элементы с большими индексами оставлены дальше. Элемент со значением CHAR_MAX означает, что дальнейшая группировка не производится. Элемент со значением 0 означает, что предыдущий элемент используется для всех оставшихся групп. */ char *grouping; /* Денежная информация. */ /* Первые три символа являются символами валют из ISO 4217. Четвертый символ является разделителем. Пятый символ '\0'. */ char *int_curr_symbol; char *currency_symbol; /* Символ местной валюты. */ char *mon_decimal_point; /* Символ десятичной точки. */ char *mon_thousands_sep; /* Разделитель тысяч. */ char *mon_grouping; /* Аналогично элементу 'группировки' (выше). */ char *positive_sign; /* Знак для положительных значений. */ char *negative_sign; /* Знак для отрицательных значений. */ char int_frac_digits; /* Международные цифры дробей. */ char frac_digits; /* Местные цифры дробей. */ /* 1, если символ валюты перед положит, значением, 0, если после. */ char p_cs_precedes; /* 1, если символ валюты отделяется от положит, значения пробелом. */ char p_sep_by_space; /* 1, если символ валюты перед отриц. значением, 0, если после. */ char n_cs_precedes; /* 1, если символ валюты отделяется от отриц. значения пробелом. */ char n_sep_by_space; /* Размещение положительного и отрицательного знака: 0 Количество и символ валюты окружены скобками. 1 Строка знака перед количеством и символом валюты. 2 Строка знака за количеством и символом валюты. 3 Строка знака непосредственно перед символом валюты. 4 Строка знака непосредственно после символа валюты. */ char p_sign_posn; char n_sign_posn; /* 1, если int_curr_symbol до положит. значения, 0, если после. */ char int_p_cs_precedes; /* 1, если int_curr_symbol отделен от положит, знач. пробелом. */ char int_p_sep_by_space; /* 1, если int_curr_symbol перед отриц. значением, 0, если после. */ char int_n_cs_precedes; /* 1, если int_curr_symbol отделен от отриц. знач. пробелом. */ char int_n_sep_by_space; /* Размещение положительного и отрицательного знака: 0 Количество и int_curr_symbol окружены скобками. 1 Строка знака до количества и int_curr_symbol. 2 Строка знака после количества и int_curr_symbol. 3 Строка знака непосредственно до int_curr_symbol. 4 Строка знака непосредственно после int_curr_symbol. */ char int_p_sign_posn; char int_n_sign_posn;};Комментарии показывают довольно ясно, что происходит. Давайте посмотрим на несколько первых полей
struct lconvdecimal_pointИспользуемый символ разделителя десятичной дроби. В Соединенных Штатах и других англоязычных странах это точка, но во многих странах используется запятая.
thousands_sepСимвол, используемый для разделения каждых 3 цифр значения.
groupingМассив однобайтных целых значений. Каждый элемент указывает, сколько цифр в группе. Как сказано в комментарии,
CHAR_MAXint_curr_symbolЭто международный символ для местной валюты. Например, 'USD' для доллара США.
currency_symbolЛокальный символ для местной валюты. Например, $ для доллара США.
mon_decimal_pointmon_thousands_sepmon_groupingСоответствуют предыдущим полям, предоставляя те же сведения, но для денежных сумм.
Большая часть оставшихся значений не имеет значения для повседневного программирования. Следующая программа,
ch13-lconv.c/* ch13-lconv.c --- показывает некоторые компоненты struct lconv */#include #include #include int main(void) { struct lconv l; int i; setlocale(LC_ALL, ""); l = *localeconv(); printf("decimal_point = [%s]\n", l.decimal_point); printf("thousands_sep = [%s]\n", l.thousands_sep); for (i = 0; l.grouping[i] != 0 && l.grouping[i] != CHAR_MAX; i++) printf("grouping[%d] = [%dj\n", i, l.grouping[i]); printf("int_curr_symbol = [%s]\n", l.int_curr_symbol); printf("currency_symbol = f%s]\n", l.currency_symbol); printf("mon_decimal_point = f%s]\n", l.mon_decimal_point); printf("mon_thousands_sep = [%s]\n", l.mon_thousands_sep); printf("positive_sign = [%s]\n", l.positive_sign); printf("negative_sign = [%s]\n", l.negative_sign);}Неудивительно, при запуске в различных локалях мы получаем различные результаты.
$ LC_ALL=en_US ch13-lconv /* Результаты для Соединенных Штатов */decimal_point = [.]thousands_sep = [,]grouping[0] = [3]grouping[1] = [3]int_curr_symbol = [USD ]currency_symbol = [$]mon_decimal_point = [.]mon_thousands_sep = [,]positive_sign = []negative_sign = [-]$ LC_ALL=it_IT ch13-lconv /* Результаты для Италии */decimal_point = [.]thousands_sep = []int_curr_symbol = []currency_symbol = []mon_decimal_point = []mon_thousands_sep = []positive_sign = []negative_sign = []Обратите внимание, что значение
int_curr_symbolen_US
13.2.5. Высокоуровневое числовое и денежное форматирование: strfmon()
и printf()
strfmon()printf()После рассмотрения всех полей
struct lconvstrfmon()#include /* POSIX */ ssize_t strfmon(char *s, size_t max, const char *format, ...);Эта функция во многом подобна
strftime()strftime()formatsch13-strfmon.cstrfmon()/* ch13-strfmon.c --- демонстрация strfmon() */#include #include #include int main(void) { char buf[BUFSIZ]; double val = 1234.567; setlocale(LC_ALL, ""); strfmon(buf, sizeof buf, "You owe me %n (%i)\n", val, val); fputs(buf, stdout); return 0;}При запуске в двух различных локалях она выдает такой результат:
$ LC_ALL=en_US ch13-strfmon /* В Соединенных Штатах */You owe me $1,234.57 (USD 1,234.57)$ LC_ALL=it_IT ch13-strfmon /* В Италии */You owe me EUR 1.235 (EUR 1.235)Как вы можете видеть,
strfmon()strftime()%n %i %% %Форматируемые значения должны иметь тип
double%n%ien_US%n$%iГибкость — и соответственно определенная сложность — сопровождают многие функции API, разработанные для POSIX, и
strfmon()printf()%in%[флаги][ширина поля][#точность_слева][.точность_справа]i%[флаги][ширина поля][#точность_слева][.точность_справа]n%% /* Не допускаются поля флагов, ширины и т.д. */Флаги перечислены в табл. 13.2.
Таблица 13.2. Флаги для
strfmon()| Флаг | Значение |
|---|---|
|
Использовать символ с в качестве символа числового заполнения слева. Символом по умолчанию является пробел. Обычной альтернативой является 0 |
|
Запретить использование символа группировки (например, запятой в Соединенных Штатах) |
|
Отрицательные значения заключать в скобки. Несовместим с флагом |
|
Обрабатывать положительные/отрицательные значения обычным образом. Использовать положительные и отрицательные знаки локали. Несовместим с флагом |
|
Не включать символ валюты. Этот флаг полезен, если вы хотите использовать |
|
Выровнять результат слева. По умолчанию используется выравнивание справа. Этот флаг не действует без указания ширины поля |
Ширина поля является строкой десятичных цифр, представляющих минимальную ширину. По умолчанию использует столько символов, сколько необходимо, основываясь на оставшейся части спецификации. Значения, меньшие ширины поля, дополняются пробелами слева (или справа, если указан флаг '
-Точность слева состоит из символа
#=Наконец, точность справа состоит из символа '
.frac_digitsint_frac_digitsstruct lconvstrfmon()errnoE2BIGПомимо
strfmon()'printf()%i%d%u%f%F%g%Gch13-quoteflag.c/* ch13-quoteflag.c --- демонстрация флага кавычки printf */#include #include int main(void) { setlocale(LC_ALL, ""); /* Это нужно, иначе не будет работать */ printf("%'d\n", 1234567);return 0;}Вот что происходит для двух различных локалей: в одной есть разделитель тысяч, в другой нет:
$ LC_ALL=C ch13-quoteflag /* Обычное окружение без разделителя */1234567$ LC_ALL=en_US ch13-quoteflag /* Локаль с разделителем (англ.) */1,234,567На время написания лишь GNU/Linux и Solaris поддерживают флаг
'
13.2.6. Пример: форматирование числовых значений в gawk
gawkgawkprintf()sprintf()gawk'builtin.cgawkgawkstruct lconv1 case 'd':2 case 'i':3 ...4 tmpval = force_number(arg);56 ...7 uval = (uintmax_t)tmpval;8 ...9 ii = jj = 0;10 do {11 *--cp = (char)('0' + uval % 10);12 #ifdef HAVE_LOCALE_H13 if (quote_flag && loc.grouping[ii] && ++jj == loc.grouping[ii]) {14 *--cp = loc.thousands_sep[0]; /* XXX - предположение, что это один символ */15 if (loc.grouping[ii+1] == 0)16 jj = 0; /* продолжить использовать текущий val в loc.grouping [ii] */17 else if (loc.grouping[ii+1] == CHAR_MAX)18 quote_flag = FALSE;19 else {20 ii++;21 jj = 0;22 }23 }24 #endif25 uval /= 10;26 } while (uval > 0);(Номера строк даны относительно начала фрагмента.) Некоторые части кода, не имеющие отношения к обсуждению, были опущены, чтобы облегчить фокусировку на важных частях.
Переменная
locstruct lconvmain()loc.thousands_seploc.groupingCHAR_MAXС таким введением, давайте посмотрим на код. Строка 7 устанавливает
uvaliijjloc.groupingquote_flag'Цикл
do-whileНас интересуют строки 12–24. Эта работа осуществляется только на системе, поддерживающей локали, на что указывает наличие заголовочного файла
HAVE_LOCALEКогда условие в строке 13 истинно, настало время добавить символ разделителя тысяч. Это условие можно прочесть как «если требуется группировка и текущее положение в
loc.groupingПосле использования текущего положения в
loc.groupingjjCHAR_MAXquote_flagjjiiЭто низкоуровневый, подробный код. Однако, поняв один раз, как представляется информация в
struct lconv
13.2.7. Форматирование значений даты и времени: ctime()
и strftime()
ctime()strftime()В разделе 6.1 «Времена и даты» описаны функции для получения и форматирования значений времени и даты. Функция
strftime()setlocale()ch13-times.с/* ch13-times.c --- демонстрация времени на основе локали */#include #include #include int main(void) { char buf[100]; time_t now; struct tm *curtime; setlocale(LC_ALL, ""); time(&now); curtime = localtime(&now); (void)strftime(buf, sizeof buf, "It is now %A, %B %d, %Y, %I:%M %p", curtime); printf("%s\n", buf); printf("ctime() says: %s", ctime(&now)); exit(0);}При запуске программы мы видим, что результаты
strftime()ctime()$ LC_ALL=en_US ch13-times /* Время в Соединенных Штатах */It is now Friday, July 11, 2003, 10:35 AMctime() says: Fri Jul 11 10:35:55 2003$ LC_ALL=it_IT ch13-times /* Время в Италии */It is now venerdi, luglio 11, 2003, 10:36ctime() says: Fri Jul 11 10:36:00 2003$ LC_ALL=fr_FR ch13-times /* Время во Франции */It is now vendredi, juillet 11, 2003, 10:36ctime() says: Fri Jul 11 10:36:05 2003Причина отсутствия изменений в том, что
ctime()asctime()ctime()strftime()
13.2.8. Другие данные локали: nl_langinfo()
nl_langinfo()Хотя ранее мы сказали, что API
catgets()nl_langinfo()struct lconv#include #include char *nl_langinfo(nl_item item);Заголовочный файл
nl_itemintenumitemstrftime()Доступная информация поступает из нескольких категорий локали. В табл. 13.3 перечислены константы элементов, соответствующие категории локали и их значения.
Таблица 13.3. Значения элементов для
nl_langinfo()| Элемент | Категория | Значение |
|---|---|---|
|
|
Сокращенные названия дней недели. Воскресенье является днем 1 |
|
|
Сокращенные названия месяцев |
|
|
Альтернативные символы для цифр; см. текст |
|
|
Обозначения a.m/p.m. для локали. |
|
|
Имя кодовой страницы для локали, т.е. использующиеся набор символов и кодировка |
|
|
Символ местной валюты, описанный ниже |
|
|
Названия дней недели. Воскресенье является днем 1 |
|
|
Формат даты |
|
|
Формат даты и времени |
|
|
Формат даты эры. |
|
|
Формат даты и времени эры. |
|
|
Формат времени эры. |
|
|
Сегменты описания эры, см. текст. |
|
|
Названия месяцев. |
|
|
Символ системы счисления. Для базы 10 это символ точки в десятичной дроби. |
|
|
Символ-разделитель тысяч |
|
|
Формат времени в записи a.m/p.m. |
|
|
Формат времени. |
|
|
Строка, представляющая положительный и отрицательный ответы. |
Эра является определенным временем в истории. Поскольку она имеет отношение к датам и временам, она имеет наибольший смысл в странах, управляемых императорами и династиями.[144]
Спецификации эр POSIX могут определять эры ранее 1 г. н.э. В таких случаях у начальной даты большее абсолютное числовое значение, чем у конечной даты. Например, Александр Великий правил с 336 г. до н.э. по 323 г до н.э.
Значение, возвращенное '
nl_langinfo(ERA)NULL;:Таблица 13.4. Компоненты спецификации эры
| Компонент | Значение |
|---|---|
| Направление | Символы ' |
| Смешение | Ближайший к дате начала эры год |
| Дата начала | Дата начала эры в виде 'гггг/мм/дд'. Это соответственно год, месяц и день. Годы до н.э используют для гггг отрицательные значения |
| Дата конца | Дата завершения эры в том же самом виде. Допустимы два дополнительных вида: |
| Название эры | Название эры, соответствующее спецификации преобразования |
| Формат эры | Формат года в пределах эры, соответствующий спецификации преобразования |
Значение
ALT_DIGITS%OCstrftime()nl_langinfo(ALT_DIGITS)Наконец, '
nl_langinfo(CRNCYSTR)-+.- + . 13.3. Динамический перевод сообщений программ
Только что освещенные интерфейсы стандартной библиотеки С решают простые части проблемы локализации. Для денежных, числовых значений, значений времени и даты, также, как для проблем сортировки строк, применяется управление посредством таблиц специфичных для локали данных (таких, как списки названий месяцев и дней).
Однако, большая часть взаимодействия пользователя с текстовой программой осуществляется в виде выводимых сообщений, таких, как приглашения или сообщения об ошибках. Проблема заключается в необходимости избежания множества версий одной и той же программы, которые отличаются лишь содержанием строк сообщений. Решением де-факто в мире GNU является GNU
gettextGNU
gettext
13.3.1. Установка текстового домена: textdomain()
textdomain()Законченное приложение может содержать множество компонентов: отдельные исполняемые файлы, написанные на С или C++ или на языках сценариев, которые также могут получить доступ к возможностям
gettextgawkgawkcoreutilstextdomain()#include /* GLIBC */ char* textdomain(const char *domainname)Каждый компонент должен вызывать эту функцию со строкой, указывающей на текстовый домен, в составе первоначальной инициализации в
main()domainnameNULLNULLЕсли текстовый домен не установлен с помощью
textdomain()messages
13.3.2. Перевод сообщений: gettext()
gettext()Следующим после установки текстового домена шагом является использование функции
gettext()#include /* GLIBC */ char *gettext(const char *msgid);char *dgettext(const char *domainname, const char *msgid);char *dcgettext(const char *domainname, const char *msgid, int category);Аргументы, используемые в этих функциях, следующие:
const char *msgidПереводимая строка. Она действует в качестве ключа к базе данных переводов.
const char *domainnameТекстовый домен, из которого нужно получить перевод. Таким образом, хотя
main()textdomain()int categoryОдна из описанных ранее категорий доменов (
LC_TIMEtextdomain()messagestextdomain()LC_MESSAGESmain()textdomain("killerapp");Тогда '
gettext("my message")dgettext("killerapp", "my message")dcgettext("killerapp", "my message", LC_MESSAGES)В 99,9% времени бывает нужно использовать
gettext()Все функции возвращают строки. Строка является либо переводом данного
msgid/* Каноническая первая программа, локализованная версия. */#include #include #include int main(void) { setlocale(LC_ALL, ""); printf("%s\n", gettext("hello, world")); return 0;}Хотя сообщение является простой строкой, мы не используем ее непосредственно в форматирующей строке
printf()%Вскоре, в разделе 13.3.4 «Упрощение использования
gettext()gettext()
13.3.3. Работа с множественными числами: ngettext()
ngettext()Перевод во множественном числе доставляет дополнительные трудности. Простой код мог бы выглядеть примерно так:
printf("%d word%s misspelled\n", nwords, nwords > 1 ? "s" : "");/* или */printf("%d %s misspelled\n", nwords, nwords == 1 ? "word" : "words").Это подходит для английского языка, но перевод становится трудным. Во-первых, во многих языках множественное число не образуется с такой же легкостью, как в английском (добавлением суффикса
sif (nwords == l) printf("one word misspelled\n");else printf("%d words misspelled\n", nwords);Решением является параллельный набор процедур специально для форматирования множественных значений:
#include /* GLIBC */ char *ngettext(const char *msgid, const char *msgid_plural, unsigned long int n);char *dngettext(const char *domainname, const char *msgid, const char *msgid_plural, unsigned long int n);char *dcngettext(const char *domainname, const char *nmgid, const char *msgid_plural, unsigned long int n, int category)Помимо первоначального аргумента
msgidconst char *msgid_pluralСтрока по умолчанию для использования в качестве множественного числа. Вскоре будут примеры.
unsigned long int nЧисло имеющихся элементов.
Список сообщений каждой локали указывает, как переводить множественные числа.[145] Функция
ngettext()nmsgidmsgidngettext()msgidn == 1msgid_pluralprintf("%s\n", ngettext("%d word misspelled", "%d words misspelled", nwords), nwords);Обратите внимание, что
nwordsngettext()printf()n++ngettext()
13.3.4. Упрощение использования gettext()
Вызов
gettext()
в исходном коде программы служит двум целям. Во-первых, он осуществляет перевод во время исполнения, что является в конце концов главным. Однако, он служит также для отметки строк, которые нужно перевести. Утилита xgettext
читает исходный код программы и извлекает все оригинальные строки, которые нужно перевести. (Далее в главе мы кратко рассмотрим это.)
Рассмотрим все-таки случай, когда статические строки не используются непосредственно:
static char *copyrights[] = {
"Copyright 2004, Jane Programmer",
"Permission is granted ...",
/* ... Здесь куча легальностей */
NULL
};
void copyright(void) {
int i;
for (i = 0; copyrights[i] != NULL, i++)
printf("%s\n", gettext(copyrights[i]));
}
Здесь мы хотели бы иметь возможность вывести переводы строк об авторских правах, если они доступны. Однако, как извлекающее устройство
xgettext
предполагает найти эти строки? Мы не можем заключить их в вызовы gettext()
, поскольку это не будет работать во время компиляции:
/
* ПЛОХОЙ КОД: не будет компилироваться */
static char *copyrights[] = {
gettext("Copyright 2004, Jane Programmer"),
gettext("Permission is granted ..."),
/* ... Здесь куча легальностей */
NULL
};
13.3.4.1. Переносимые программы: "gettext.h
"
Здесь мы предполагаем, что вы хотите написать программу, которая может использоваться вместе с библиотекой GNU
gettext
на любой системе Unix, а не только GNU/Linux. Следующий раздел описывает, что сделать для программ только для GNU/Linux.
Пометка строк включает два шага. Первый заключается в использовании вспомогательного заголовка
gettext.h
, который поставляется с дистрибутивом GNU gettext
. Этот файл обрабатывает несколько проблем переносимости и компиляции, упрощая использование gettext()
в ваших собственных программах:
#define ENABLELNLS 1 /* ENABLE_NLS должен быть true, чтобы gettext() работала */
#include "gettext.h" /* Вместо */
Если макрос
ENABLE_NLS
не определен[146] или установлен в ноль, gettext.h
развертывает вызовы gettext()
в первый аргумент. Это делает возможным перенос кода, использующего gettext()
, на системы, в которых не установлены ни GNU gettext
, ни собственная их версия. Помимо прочего, этот заголовочный файл определяет следующий макрос:
/* Вызов псевдофункции, который служит в качестве маркера для
автоматического извлечения сообщений, но не осуществляющий вызов
gettext(). Перевод времени исполнения осуществляется в другом
месте кода. Аргумент String должен быть символической строкой.
Сцепленные строки и другие строковые выражения не будут работать.
Разворачивание макроса не параметризовано, так что он подходит для
инициализации статических переменных 'char[]' или 'const char[]'. */
#define gettext_noop(String) String
Комментарий самодостаточен. С помощью этого макроса мы можем теперь перейти ко второму шагу. Мы перепишем код следующим образом:
#define ENABLE_NLS 1
#include "gettext.h"
static char copyrights[] =
gettext_noop("Copyright 2004, Jane Programmer\n"
"Permission is granted ...\n"
/* ... Здесь куча легальностей */
"So there.");
void copyright(void) {
printf("%s\n", gettext(copyrights));
}
Обратите внимание, что мы сделали два изменения. Во-первых,
copyrights
теперь является одной длинной строкой, созданной с использованием возможности конкатенации строк стандартного C. Эта простая строка затем включена в вызов gettext_noop()
. Нам нужна одна строка, чтобы легальности могли быть переведены в виде одного элемента
Второе изменение заключается в непосредственном выводе перевода в виде одной строки в
copyright()
.
К этому времени вы, возможно, думаете: «Вот здорово, набирать каждый раз '
gettext(...)
' довольно неприятно». Ну, вы правы. Это не только создает лишнюю работу по набиванию, но также и затрудняет чтение исходного кода. Соответственно, когда вы используете заголовочный файл gettext.h
, руководство GNU gettext
рекомендует включить два других макроса с именами _()
и N_()
следующим образом:
#define ENABLE_NLS 1
#include "gettext.h"
#define _(msgid) gettext(msgid)
#define N_(msgid) msgid
Такой подход снижает накладные расходы по использованию
gettext()
всего лишь тремя дополнительными символами для переводимой строковой константы и всего лишь четырьмя символами для статических строк:
#include
#define ENABLE_NLS 1
#include "gettext.h"
#define _(msgid) gettext(msgid)
#define N_(msgid) msgid
...
static char copyrights[] =
N_("Copyright 2004, Jane Programmer\n"
"Permission is granted ...\n"
/* ... Здесь куча легальностей */
"So there.");
void copyright(void) {
printf("%s\n", gettext(copyrights));
}
int main(void) {
setlocale(LC_ALL, ""); /* gettext.h gets for us too */
printf("%s\n", _("hello, world"));
copyright();
exit(0);
}
Эти макросы скромны, и на практике все GNU программы, использующие GNU
gettext
, следуют этому соглашению. Если вы собираетесь использовать GNU gettext
, вам тоже нужно следовать этому соглашению.
13.3.4.2. Только GLIBC:
Для программ, которые будут использоваться лишь на системах с GLIBC, использование заголовочных файлов и макросов похоже, но проще:
#include
#include
#define _(msgid) gettext(msgid)
#define N_(msgid) msgid
/* ... все остальное то же ... */
Как мы видели ранее, заголовочный файл
объявляет gettext()
и другие функции. Вам все равно нужно определять _()
и N_()
, но не нужно беспокоиться о ENABLE_NLS
или включении с исходным кодом вашей программы файла gettext.h
.
gettext()Вызов
gettext()xgettextРассмотрим все-таки случай, когда статические строки не используются непосредственно:
static char *copyrights[] = { "Copyright 2004, Jane Programmer", "Permission is granted ...", /* ... Здесь куча легальностей */ NULL};void copyright(void) { int i; for (i = 0; copyrights[i] != NULL, i++) printf("%s\n", gettext(copyrights[i]));}Здесь мы хотели бы иметь возможность вывести переводы строк об авторских правах, если они доступны. Однако, как извлекающее устройство
xgettextgettext()/
* ПЛОХОЙ КОД: не будет компилироваться */static char *copyrights[] = { gettext("Copyright 2004, Jane Programmer"), gettext("Permission is granted ..."), /* ... Здесь куча легальностей */ NULL};
13.3.4.1. Переносимые программы: "gettext.h
"
gettext.hЗдесь мы предполагаем, что вы хотите написать программу, которая может использоваться вместе с библиотекой GNU
gettextПометка строк включает два шага. Первый заключается в использовании вспомогательного заголовка
gettext.hgettextgettext()#define ENABLELNLS 1 /* ENABLE_NLS должен быть true, чтобы gettext() работала */#include "gettext.h" /* Вместо */ Если макрос
ENABLE_NLSgettext.hgettext()gettext()gettext/* Вызов псевдофункции, который служит в качестве маркера для автоматического извлечения сообщений, но не осуществляющий вызов gettext(). Перевод времени исполнения осуществляется в другом месте кода. Аргумент String должен быть символической строкой. Сцепленные строки и другие строковые выражения не будут работать. Разворачивание макроса не параметризовано, так что он подходит для инициализации статических переменных 'char[]' или 'const char[]'. */#define gettext_noop(String) StringКомментарий самодостаточен. С помощью этого макроса мы можем теперь перейти ко второму шагу. Мы перепишем код следующим образом:
#define ENABLE_NLS 1#include "gettext.h"static char copyrights[] = gettext_noop("Copyright 2004, Jane Programmer\n" "Permission is granted ...\n" /* ... Здесь куча легальностей */ "So there.");void copyright(void) { printf("%s\n", gettext(copyrights));}Обратите внимание, что мы сделали два изменения. Во-первых,
copyrightsgettext_noop()Второе изменение заключается в непосредственном выводе перевода в виде одной строки в
copyright()К этому времени вы, возможно, думаете: «Вот здорово, набирать каждый раз '
gettext(...)gettext.hgettext_()N_()#define ENABLE_NLS 1#include "gettext.h"#define _(msgid) gettext(msgid)#define N_(msgid) msgidТакой подход снижает накладные расходы по использованию
gettext()#include #define ENABLE_NLS 1#include "gettext.h"#define _(msgid) gettext(msgid)#define N_(msgid) msgid...static char copyrights[] = N_("Copyright 2004, Jane Programmer\n" "Permission is granted ...\n" /* ... Здесь куча легальностей */ "So there.");void copyright(void) { printf("%s\n", gettext(copyrights));}int main(void) { setlocale(LC_ALL, ""); /* gettext.h gets for us too */ printf("%s\n", _("hello, world")); copyright(); exit(0);}Эти макросы скромны, и на практике все GNU программы, использующие GNU
gettextgettext
13.3.4.2. Только GLIBC:
Для программ, которые будут использоваться лишь на системах с GLIBC, использование заголовочных файлов и макросов похоже, но проще:
#include #include #define _(msgid) gettext(msgid)#define N_(msgid) msgid/* ... все остальное то же ... */Как мы видели ранее, заголовочный файл
gettext()_()N_()ENABLE_NLSgettext.h
13.3.5. Перестановка порядка слов с помощью printf()
printf()Иногда при переводах порядок слов, естественный для английского языка, не подходит в других языках. Например, на английском прилагательные идут перед определяемыми существительными, а на многих других языках — после. Таким образом, следующий код представляет проблему:
char *animal_color, *animal;if (...) { animal_color = _("brown"); animal = _("cat");} else if (...) { ...} else { ...}printf(_("the %s %s looks at you enquiringly.\n"), animal_color, color);Здесь форматирующая строка,
animal_coloranimalgettext()Чтобы обойти это, версия семейства
printf()$%printf("%2$s, %1s\n", "world", "hello")Указатель положения обозначает аргумент из списка, который следует использовать, отсчет начинается с 1 и не включает саму форматирующую строку. Этот пример выводит знаменитое сообщение '
hello, worldGLIBC и Solaris реализуют эту возможность. Поскольку это часть POSIX, если
printf()За указателем положения могут следовать любые обычные флаги
printf()• Форма с указателем положения не может смешиваться с формой без нее. Другими словами, или каждый указатель формата включает указатель положения, или ни один его не включает. Конечно,
%%• Если в форматирующей строке используется N-й аргумент, в этой строке должны использоваться также все аргументы до N. Соответственно, следующее неверно
printf("%3$s %1$s\n", "hello", "cruel", "world")• Ссылка на определенный аргумент может быть сделана указателем положения несколько раз. Не позиционные спецификаторы формата всегда движутся через список аргументов последовательно.
Эта возможность не предназначена для непосредственного использования программистами приложений, она скорее для переводчиков. Например, перевод предыдущей форматирующей строки,
"The %s %s looks at you enquiringly.\n""Le %2$s %1$s te regarde d'un aire interrogateur.\n"(Даже этот перевод не совершенен: артикль «Le» имеет род. Подготовка программы к переводу трудная задача!)
13.3.6. Тестирование переводов в персональном каталоге
Коллекция сообщений в программе называется списком сообщений (message catalog). Этот термин применяется также к каждому из переводов сообщений на другой язык. Когда программа установлена, каждый перевод также устанавливается в стандартное место, где
gettext()Может оказаться полезным разместить переводы не в стандартном, а в другом каталоге, особенно для тестирования программы. Особенно на больших системах, у обычного пользователя может не быть необходимых разрешений для установки файлов в системные каталоги. Функция
bindtextdomain()gettext()#include /* GLIBC */ char *bindtextdomain(const char *domainname,const char *dirname);Полезные каталоги включают '
./tmpchar *td_dir;setlocale(LC_ALL, "");textdomain("killerapp");if ((td_dir = getenv("KILLERAPP_TD_DIR")) != NULL) bindtextdomain("killerapp", td_dir);bindtextdomain()gettext()13.3.7. Подготовка интернационализированных программ
К настоящему моменту мы рассмотрели все компоненты, из которых состоит интернационализированная программа. Данный раздел подводит итоги.
1. Включите в свое приложение заголовочный файл
gettext.h_()N_()ENABLE_NLS2. Вызовите соответствующим образом
setlocale()setlocale(LC_ALL, "")3. Выберите для приложения текстовый домен и установите его с помощью
textdomain()4. При тестировании свяжите текстовый домен с определенным каталогом при помощи
bindtextdomain()5. Используйте соответствующим образом
strfmon()strftime()'nl_langinfo()strftime()6. Пометьте все строки, которые должны быть переведены, соответствующими вызовами
_()N_()Хотя некоторые не следует так помечать. Например, если вы используете
getopt_long()%d %d\n7. В нужных местах используйте
ngettext()8. Упростите жизнь для своих переводчиков, используя строки с полными предложениями вместо замены слов с помощью
%s?:if (/* возникла ошибка */) { /* ВЕРНО */ /* Использовать несколько строк для упрощения перевода. */ if (input_type == INPUT_FILE) fprintf(stderr, _("%s: cannot read file: %s\n"), argv[0], strerror(errno)); else fprintf(stderr, _("%s: cannot read pipe: %s\n"), argv[0], strerror(errno));Это лучше, чем
if (/* возникла ошибка */) { /* НЕВЕРНО */ fprintf(stderr, _("%s: cannot read %s: %s\n"), argv[0], input_type == INPUT_FILE ? _("file") : _("pipe"), strerror(errno));}Как только что показано, хорошей мыслью является включение комментария, сообщающего о намеренном использовании нескольких строк, чтобы упростить перевод сообщений.
13.3.8. Создание переводов
После интернационализации программы необходимо подготовить переводы. Это осуществляется с помощью нескольких инструментов уровня оболочки. Мы начнем с интернационализированной версии
ch06-echodate.ctime_t/* ch13-echodate.c --- демонстрация переводов */#include #include #include #define ENABLE_NLS 1#include "gettext.h"#define _(msgid) gettext(msgid)#define N_(msgid) msgidint main (void) { struct tm tm; time_t then; setlocale(LC_ALL, ""); bindtextdomain("echodate", "."); textdomain("echodate"); printf("%s", _("Enter a Date/time as YYYY/MM/DD HH:MM:SS : ")); scanf("%d/%d/%d %d:%d:%d", &tm.tm_year, &tm.tm_mon, &tm.tm_mday, &tm.tm_hour, &tm.tm_min, &tm.tm_sec); /* Проверка ошибок для краткости опущена. */ tm.tm_year -= 1900; tm.tm_mon -= 1; tm.tm_isdst = -1; /* О летнем времени ничего не известно */ then = mktime(&tm); printf(_("Got: %s"), ctime(&then)); exit(0);}Мы намеренно использовали
"gettext.h"gettext"gettext.h"gettextПереходя к созданию переводов, первым шагом является извлечение переводимых строк. Это осуществляется программой
xgettext$ xgettext --keyword=_ --keyword=N_ \> --default-domain=echodate ch13-echodate.сОпции
--keywordxgettext_()N_()gettext()gettext_noop()Вывод
xgettextmessages.ро"messages"--default-domainechodate.ро# SOME DESCRIPTIVE TITLE. /* Шаблон, нужно отредактировать */# Copyright (С) YEAR THE PACKAGE'S COPYRIGHT HOLDER# This file is distributed under the same license as the PACKAGE package.# FIRST AUTHOR , YEAR. ##, fuzzymsgid "" /* Подробная информация */msgstr "" /* Заполняет каждый переводчик */"Project-Id-Version: PACKAGE VERSION\n""Report-Msgid-Bugs-To: \n""POT-Creation-Date: 2003-07-14 18:46-0700\n""PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n""Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "MIME-Version: 1.0\n""Content-Type: text/plain; charset=CHARSET\n""Content-Transfer-Encoding: 8bit\n"#: ch13-echodate.c:19 /* Местоположение сообщения */msgid "Enter a Date/time as YYYY/MM/DD HH:MM:SS : " /* Оригинальное сообщение */msgstr "" /* Здесь перевод */#: ch13-echodate.с:32 /* To же самое для каждого сообщения */#, с-formatmsgid "Got: %s"msgstr ""Этот первоначальный файл используется повторно для каждого перевода. Таким образом, это шаблон для переводов, и по соглашению, для отображения этого факта он должен быть переименован с расширением
.pot$ mv echodate.ро echodate.potHe владея свободно несколькими языками, мы решили перевести сообщения на свинский латинский. Следующим шагом является создание перевода. Это осуществляется копированием файла шаблона и добавлением к новой копии перевода:
$ cp echodate.pot piglat.po$ vi piglat.po /* Добавить переводы, используя любимый редактор */Имя по соглашению должно быть
язык.poязыкязык_страна.popt_BR.popiglat.ро# echodate translations into pig Latin# Copyright (C) 2004 Prentice-Hall# This file is distributed under the same license as the echodate package.# Arnold Robbins 2004 ##, fuzzymsgid ""msgstr """Project-Id-Version: echodate 1.0\n""Report-Msgid-Bugs-To: arnold@example.com\n""POT-Creation-Date: 2003-07-14 18:46-0700\n""PO-Revision-Date: 2003-07-14 19:00+8\n""Last-Translator: Arnold Robbins \n" "Language-Team: Pig Latin \n" "MIME-Version: 1.0\n""Content-Type: text/plain; charset=ASCII\n""Content-Transfer-Encoding: 8bit\n"#: ch13-echodate.с:19msgid "Enter a Date/time as YYYY/MM/DD HH:MM:SS : "msgstr "Enteray A Ateday/imetay asay YYYY/MM/DD HH:MM:SS : "#: ch13-echodate.c:32#, c-formatmsgid "Got: %s"msgstr "Otgay: %s"Хотя можно было бы произвести линейный поиск в переносимом объектном файле, такой поиск был бы медленным. Например, в
gawkgettextmsgfmt$ msgfmt piglat.po -о piglat.moПри сопровождении программы изменяются строки, используемые программой: добавляются новые, другие удаляются или изменяются. По крайней мере, может измениться положение строки в исходном файле. Таким образом, файлы переводов
.роmsgmerge.pot$ msgmerge piglat.po echodate.pot -o piglat.new.po /* Объединить файлы */$ mv piglat.new.po piglat.po /* Переименовать результат */$ vi piglat.po /* Модернизировать перевод */$ msgfmt piglat.po -o piglat.mo /* Восстановить файл .mo */Откомпилированные файлы
.mobase/locale/category/textdomain.mobase/usr/share/localelocaleesfrcategoryLC_MESSAGEStextdomainechodate/usr/share/locale/es/LC_MESSAGES/coreutils.moФункция
bindtextdomain()basech13-echodate.c.$ mkdir -р en_US/LC_MESSAGES /* Нужно использовать реальную локаль */$ cp piglat.mo en_US/LC_MESSAGES/echodate.mo /* Поместить файл в нужное место */Должна использоваться реальная локаль[148]; мы «притворяемся» использующими "
en_USLC_ALL$ LC_ALL=en_US ch13-echodate /* Запуск программы */Enteray A Ateday/imetay asay YYYY/MM/DD HH:MM:SS : 2003/07/14 21:19:26Otgay: Mon Jul 14 21:19:26 2003Последнюю версию GNU
gettextgettextЭтот раздел лишь слегка коснулся поверхности процесса локализации. GNU
gettextmakegettextРекомендуем прочесть документацию GNU
gettextgettext13.4. Не могли бы вы произнести это для меня по буквам?
В самые ранние дни вычислительной техники различные системы назначали различные соответствия между числовыми значениями и глифами (glyphs) — символами, такими, как буквы, цифры и знаки пунктуации, используемыми для общения с людьми. В конечном счете появились два широко использующихся стандарта: кодировка EBCDIC, используемая IBM и подобными ей мэйнфреймами, и ASCII, использующаяся для всего остального. Сегодня, за исключением мэйнфреймов, ASCII является основой для всех других использующихся наборов символов.
Оригинальный семиразрядный набор символов ASCII достаточен для американского английского и большинства знаков пунктуации и специальных символов (таких, как
$Литература по интернационализации изобилует ссылками на три фундаментальных термина. Определив их и взаимоотношения между ними, мы сможем представить общее описание соответствующих функций API С.
Набор символов (character set)
Определение значений, присваиваемых различным целым величинам; например того, что A равно 65. Любой набор символов, использующий более восьми битов на символ, называется многобайтным набором символов.
Представление набора символов (character set encoding)
ASCII использует для представления символов один байт. Таким образом, целое значение хранится само по себе, непосредственно в дисковых файлах. Более современные наборы символов, особенно различные версии Unicode[150], используют для представления символов 16-разрядные или даже 32-разрядные целые значения. Для большинства определенных символов один, два или даже три старших байта целого значения равны нулю, что делает непосредственное хранение таких значений на диске неэффективным. Представление набора символов описывает механизм для преобразования 16- или 32-разрядных значений в последовательности от одного до шести байтов для сохранения на диске таким образом, что в целом наблюдается значительная экономия дисковой памяти.
Язык
Правила данного языка определяют использование набора символов. В частности, правила влияют на сортировку символов. Например, на французском е, é и è все должны находиться между d и f, независимо от назначенных этим символам числовых значений. Различные языки могут назначить (и назначают) одним и тем же глифам различный порядок сортировки.
Со временем для поддержки многобайтных наборов символов были разработаны различные технологии. Вычислительная практика медленно стремится к Unicode и соответствующим его представлениям, но стандартный С и POSIX поддерживают как старые, так и современные технологии. В данном разделе представлен концептуальный обзор различных возможностей. Нам самим не приходилось их использовать, поэтому мы предпочитаем просто познакомить с ними и предоставить ссылки на дополнительную информацию.
13.4.1. Широкие символы
Мы начнем с концепции широких символов (wide character). Широкий символ является целым типом, в котором может храниться любое значение из определенного используемого многобайтного набора символов.
Широкие символы представлены на С типом
wchar_twint_twchar_tWEOFEOFiswalnum()Широкие символы могут быть от 16 до 32 битов размером в зависимости от реализации. Как упоминалось, они нацелены на манипулирование данными в памяти и обычно не хранятся в файлах непосредственно.
Стандарт C предусматривает для широких символов большое число функций и макросов, соответствующих традиционным функциям, работающим с данными
charwprintf()iswlower()13.4.2. Представления многобайтных символов
Строки широких символов сохраняются на диске путем преобразования их в памяти в многобайтное представление набора символов с последующей записью в дисковый файл. Сходным образом, такие строки считываются с диска через низкоуровневый блочный ввод/вывод, а затем конвертируются в памяти из многобайтной версии в версию широких символов.
Многие описанные кодировки используют для представления многобайтных символов состояния регистра (shift states). Другими словами, в данном потоке байтов значения байтов представляют самих себя до тех пор, пока не встретится специальное управляющее значение. В этот момент интерпретация изменяется в соответствии с текущим состоянием регистра. Таким образом, одно и то же восьмибитовое значение может иметь два значения: одно для обычного состояния, без использования регистра, и другое для использования регистра. Предполагается, что правильно закодированные строки начинаются и заканчиваются с одним и тем же состоянием регистра.
Значительным преимуществом Unicode является то, что его представления являются самокорректирующимися; кодировки не используют состояния регистров, поэтому потеря данных в середине не может повредить последующим закодированным данным.
Первоначальные версии функций преобразования многобайтных символов в широкие и широких в многобайтные поддерживали закрытую копию состояния преобразования (например, состояние регистра, а также все остальное, что могло понадобиться) Такая модель ограничивает использование функции лишь одним видом преобразования в течение жизни программы. Примерами являются
mblen()mbtowc()wctomb()mbstowcs()wcstombs()Новые версии этих процедур называются повторно запускаемыми (restartable). Это означает, что код уровня пользователя сохраняет состояние преобразования в отдельном объекте типа
mbstate_tmbrlen()mbrtowc()wcrtomb()mbsrtowcs()wcsrtombs()r13.4.3. Языки
Языковые проблемы управляются локалью. Ранее в главе мы уже видели
setlocale()Правда в том, что подробности на самом деле не нужны. Вам, как разработчику программ, не нужно беспокоиться о них; как заставить все работать, зависит от разработчиков библиотек. Все, что нужно, это понять концепции и использовать в своем коде соответствующие функции, такие, как
strcoll()strcoll()strxfrm()Современные системы GLIBC предоставляют отличную поддержку локалей, включая поддерживающие локали процедуры сопоставления регулярных выражений. Например, расширенное регулярное выражение POSIX
[[:alpha:]][[:alnum:]]+eè[a-zA-Z][a-A-Zz0-9]+Таблица 13.5. Классы символов регулярных выражений POSIX
| Класс | Соответствует |
|---|---|
|
Алфавитно-цифровые символы |
|
Алфавитные символы |
|
Символы пробела и табуляции. |
|
Управляющие символы |
|
Цифровые символы |
|
Символы, являющиеся одновременно печатными и видимыми. (Символ конца строки печатный, но не видимый, тогда как |
|
Строчные алфавитные символы |
|
Печатные (не управляющие) символы |
|
Знаки пунктуации (не буквы, цифры, управляющие или пробельные символы) |
|
Пробельные символы (такие, как сам пробел, символы табуляции, конца строки и т.д) |
|
Заглавные алфавитные символы |
|
Символы из набора |
13.4.4. Заключение
Возможно, вам никогда не придется иметь дело с различными наборами символов и их представлениями. С другой стороны, мир быстро становится «глобальным сообществом», и авторы программ не могут позволить себе быть ограниченными. Следовательно, стоит знать о проблемах интернационализации и наборов символов, а также способах их влияния на поведение вашей системы. По крайней мере, уже один из поставщиков дистрибутивов GNU/Linux устанавливает для систем в Соединенных Штатах локаль по умолчанию
en_US.UTF-813.5. Рекомендуемая литература
1. С, A Reference Manual, 5th edition, by Samuel P. Harbison III and Guy L. Steele, Jr., Prentice-Hall, Upper Saddle River, New Jersey, USA, 2002. ISBN: 0-13-089592-X.
Мы уже упоминали эту книгу раньше. Она дает точное и исчерпывающее описание развития и использования возможностей стандартной библиотеки С для работы с многобайтными и широкими символами. Это особенно ценно для современных систем, поддерживающих C99, поскольку библиотека была значительно усовершенствована для стандарта С 1999 г.
2. GNU gettext tools, by Ulrich Drepper, Jim Meyering, François Pinard, and Bruno Haible. Это руководство по GNU
gettextinfo gettextftp://ftp.gnu.org/gnu/gettext/13.6. Резюме
• Интернационализация и локализация программ подпадают под общее название поддержки родного языка. Широко распространенными сокращениями являются i18n, l10n и NLS. Центральным является понятие локали, которая позволяет настраивать набор символов, отображение даты, времени, денежных и числовых величин в соответствии с принятыми для данного языка и в данной стране нормами.
• Использование локали устанавливается с помощью функции
setlocale()• Сравнение строк с учетом локали осуществляется функцией
strcoll()strxfrm()strcmp()localeconv()nl_langinfo()strfmon()strftime()printf()• Обратной стороной получения относящейся к локали информации является вывод сообщений на местном языке. Модель
catgets()gettext• При использовании
gettext()gettext()textdomain()bindtextdomain()•
gettext()ngettext()printf()• На практике GNU программы используют для пометки переводимых строк в исходных файлах заголовочный файл
gettext.h_()N_()• GNU
gettext• Наконец, стоит быть в курсе проблем наборов символов и их представлений. Поставщики программного обеспечения не могут больше позволить себе предполагать, что их пользователи хотят работать лишь на одном языке.
Упражнения
1. Поддерживает ли ваша система локали? Если да, какая локаль используется по умолчанию?
2. Просмотрите справочную страницу locale(1), если она у вас есть. Сколько имеется локалей, если вы посчитаете их с помощью '
locale -a | wc -l3. Поэкспериментируйте с
ch13-strings.сch13-lconv.cch13-strfmon.сch13-quoteflag.cch13-times.c4. Возьмите одну из своих программ. Интернационализируйте ее с использованием GNU
gettextbindtextdomain()
Глава 14
Расширенные интерфейсы
В данной главе описываются несколько расширенных API. Они сходны по своей природе с описанными ранее в книге или предоставляют дополнительные возможности. Некоторые из них трудно было свободно обсуждать, пока не были освещены предварительные темы.
Порядок представления здесь соответствует порядку глав в первой половине книги. В другом отношении темы не связаны друг с другом. Мы освещаем следующие вопросы: динамическое выделение выровненной памяти; блокировку файлов; ряд функций, работающих со значениями долей секунды; и более развитый набор функций для сохранения и получения произвольных значений данных. Если не указано противное, все API в данной главе включены в стандарт POSIX.
14.1. Выделение выровненной памяти: posix_memalign()
и memalign()
Для большинства задач отлично подходят стандартные процедуры выделения памяти —
malloc()
, realloc()
и т.д. Но иногда может понадобиться память, которая выровнена тем или иным способом. Другими словами, адрес первого выделенного байта является кратным какого-нибудь числа. (Например, на некоторых системах копирование памяти осуществляется значительно быстрее, если используются буфера, выровненные по границе слова.) Такую службу предоставляют две функции:
#include
int posix_memalign(void **memptr, size_t alignment, size_t size);
/* POSIX ADV */
void *memalign(size_t boundary, size_t size); /* Обычная */
posix_memalign()
является более новой функцией; она является частью другого необязательного расширения, «Консультативной информации» («Advisory Information»). Работа функции отличается от других функций выделения памяти Linux. При наличии проблемы она не возвращает -1. Вместо этого возвращаемое значение равно 0 при успехе или значению errno
в случае неудачи. Аргументы следующие:
void **memptr
Указатель на переменную
void*
. Указываемая переменная будет содержать адрес выделенного блока памяти. Выделенная память освобождается с помощью free()
.
size_t alignment
Требуемое выравнивание. Оно должно быть кратно
sizeof(void*)
и быть степенью двойки.
size_t size
Число выделяемых байтов.
memalign()
является нестандартной, но широко доступной функцией, которая работает сходным образом. Возвращаемое значение равно NULL
в случае неудачи и запрошенному блоку памяти при успехе, причем boundary
(степень двойки) обозначает выравнивание, a size
— затребованный размер памяти.
Традиционно выделенная
memalign()
память не могла быть освобождена с помощью free()
, поскольку memalign()
использовала для выделения памяти malloc()
и возвращала указатель на выровненный подходящим образом байт где-то внутри блока. Версия GLIBC не имеет этой проблемы. Из этих двух функций следует использовать posix_memalign()
, если она у вас есть.
14.2. Блокировка файлов
Современные системы Unix, включая GNU/Linux, дают вам возможность заблокировать часть файла или весь файл для чтения или записи. Подобно многим частям Unix API, которые были разработаны после V7, имеется несколько несовместимых способов осуществить блокировку файлов. Данный раздел рассматривает эти возможности.
14.2.1. Концепции блокировки файлов
Также, как замок на вашей двери предотвращает нежелательные проникновения в ваш дом, блокировка файла предотвращает доступ к данным в файле. Блокировка файлов была добавлена в Unix после разработки V7 (от которой происходят все современные системы Unix), и соответственно в течение некоторого времени в различных системах Unix были доступны и использовались несколько несовместимых механизмов блокировки файлов. Как в BSD Unix, так и в System V были собственные несочетающиеся вызовы для блокировки. В конечном счете POSIX формализовал способ осуществления блокировки файлов System V. К счастью, названия функций в System V и BSD были различны, так что GNU/Linux, в попытке угодить всем, поддерживает обе разновидности блокировок.
Табл. 14.1 суммирует различные виды блокировок.
Таблица 14.1. Функции блокировки файлов
Источник
Функция
Диапазон
Весь файл
Чтение/запись
Вспомогательный
Обязательный
BSD
flock()
√
√
√
POSIX
fcntl()
√
√
√
√
√
POSIX
lockf()
√
√
√
√
√
Имеются следующие аспекты блокировки файлов:
Блокировка записей
Блокировка записи является блокировкой части файла. Поскольку файлы Unix являются просто потоками байтов, было бы корректнее использовать термин блокировка диапазона (range lock), поскольку осуществляется блокировка диапазона байтов. Тем не менее, термин «блокировка записей» общеупотребительный.
Блокировка всего файла
Блокировка всего файла, как предполагает название, блокирует весь файл, даже если его размер меняется в блокированном состоянии. Интерфейс BSD предусматривает блокирование лишь всего файла. Для блокирования всего файла с использованием интерфейса POSIX указывают нулевую длину. Это интерпретируется особым образом как «весь файл».
Блокировка чтения
Блокировка чтения предотвращает запись в читаемую область. В файле может быть несколько заблокированных для чтения участков, даже в одной области файла, не мешающих друг другу, поскольку к данным осуществляется лишь доступ и они не изменяются.
Блокировка записи
Блокировка записи предоставляет исключительный доступ к записываемой области. Если эта область заблокирована также и для чтения, попытка получения блокировки записи либо блокируется, либо завершается неудачей в зависимости от запрошенного типа блокировки. После получения блокировки записи попытка получить блокировку чтения завершается неудачей.
Вспомогательная блокировка
Вспомогательная блокировка (advisory lock) тесно соответствует замку на двери. Говорят, «замки существуют для честных людей», что означает, что если кто-нибудь на самом деле захочет вломиться в ваш дом, он, возможно, найдет способ это сделать, несмотря на наличие замка в двери. То же и со вспомогательной блокировкой; она работает лишь тогда, когда тот, кто пытается получить доступ к заблокированному файлу, сначала пытается получить блокировку. Однако, программа может совершенно игнорировать вспомогательные блокировки и делать с файлом, что захочет (конечно, пока это разрешается правами допуска файла).
Обязательная блокировка
Обязательная блокировка является более строгой: когда установлена обязательная блокировка, ни один другой процесс не может получить доступ к заблокированному файлу. Любой процесс, который пытается игнорировать это, либо сам блокируется до снятия блокировки файла, либо его попытка завершится неудачей. (Под GNU/Linux по крайней мере это включает
root
!)
Вспомогательная блокировка достаточна для взаимодействующих программ, разделяющих индивидуальный файл, когда не предполагается использование этого файла ни одним другим приложением. Обязательная блокировка подходит в ситуации, когда избежание конфликта в использовании файла является критическим, как в коммерческих системах баз данных.
POSIX стандартизует лишь вспомогательную блокировку. Обязательная блокировка доступна на GNU/Linux, а также в ряде коммерческих систем Unix, но детали варьируют. Далее в данном разделе мы рассмотрим детали для GNU/Linux.
14.2.2. Блокировка POSIX: fcntl()
и lockf()
Системный вызов
fcntl()
(file control — управление файлом) используется для блокировки файла. (Другое использование fcntl()
было описано в разделе 9.4.3 «Управление атрибутами файла: fcntl()
».) Он объявлен следующим образом:
#include /* POSIX */
#include
int fcntl(int fd, int cmd); /* Not relevant for file locking */
int fcntl(int fd, int cmd, long arg); /* Not relevant for file locking */
int fcntl(int fd, int cmd, struct flock *lock);
Аргументы следующие:
fd
Дескриптор файла для открытого файла.
cmd
Одна или более именованных констант, определенных в
. Ниже они описаны более подробно.
lock
Указатель на struct flock
, описывающую нужный блок.
14.2.2.1. Описание блокировки
Прежде чем рассмотреть осуществление блокировки, давайте исследуем описание блокировки в операционной системе. Это делается при помощи структуры
struct flock
, которая описывает диапазон блокируемых байтов и вид нужной блокировки. Стандарт POSIX утверждает, что struct lock
содержит «по крайней мере» определенные члены. Это позволяет разработчикам предоставлять при желании дополнительные члены структуры. Из слегка отредактированной справочной страницы fcntl(3):
struct flock {
...
short l_type; /* Тип блокировки: F_RDLCK, F_WRLCK, F_UNLCK */
short l_whence; /* Как интерпретируется l_start:
SEEK_SET, SEEK_CUR, SEEK_END */
off_t l_start; /* Начальное блокируемое смещение */
off_t l_len; /* Число блокируемых байтов;
0 означает от начала до конца файла */
pid_t l_pid; /* PID блокирующего процесса (только F_GETLK) */
...
};
Поле
l_start
является смешением начального байта блокируемого участка. l_len
является длиной блокируемого участка, т. е. общим числом блокируемых байтов. l_whence
указывает место в файле, относительно которого отсчитывается l_start
, значения те же, что и для аргумента whence
функции lseek()
(см раздел 4.5 «Произвольный доступ: перемещения внутри файла»), отсюда и название поля. Эта структура самодостаточна: смещение l_start
и значение l_whence
не связаны с текущим файловым указателем для чтения или записи. Пример кода мог бы выглядеть таким образом:
struct employee { /* что угодно */ }; /* Описание сотрудника */
struct flock lock; /* Структура блока */
...
/* Заблокировать структуру для шестого сотрудника */
lock.l_whence = SEEK_SET; /* Абсолютное положение */
lock.l_start = 5 * sizeof(struct employee); /* Начало 6-й структуры */
lock.l_len = sizeof(struct employee); /* Блокировать одну запись */
Используя
SEEK_CUR
или SEEK_END
, вы можете заблокировать участки, начиная от текущего смещения в файле или относительно конца файла соответственно. Для этих двух случаев l_start
может быть отрицательным, пока абсолютное начало не меньше нуля. Таким образом, чтобы заблокировать последнюю запись в файле:
/* Заблокировать запись последнего сотрудника */
lock.l_whence = SEEK_END; /* Относительно EOF */
lock.l_start = -1 * sizeof (struct employee);
/* Начало последней структуры */
lock.l_len = sizeof(struct employee); /* Заблокировать одну запись */
Установка
l_len
в 0 является особым случаем. Он означает блокировку файла от начального положения, указанного с помощью l_start
и l_whence
, и до конца файла. Сюда входят также любые области за концом файла. (Другими словами, если заблокированный файл увеличивается в размере, область блокировки расширяется таким образом, чтобы продолжать охватывать весь файл.) Таким образом, блокирование всего файла является вырожденным случаем блокирования одной записи:
lock.l_whence = SEEK_SET; /* Абсолютное положение */
lock.l_start = 0; /* Начало файла */
lock.l_len = 0; /* До конца файла */
Справочная страница fnctl(3) имеет примечание:
POSIX 1003.1-2001 допускает отрицательные значения
l_len
. (И если это так, описываемый блоком интервал охватывает байты с l_start + l_len
вплоть до l_start - 1
включительно.) Однако, в этой ситуации системный вызов Linux для современных ядер возвращает EINVAL
.
(Мы заметили, что справочная страница относится к версиям ядер 2.4.x; стоит проверить текущую справочную страницу, если ваша система новее.)
Теперь, когда мы знаем, как описать где блокируется файл, мы можем описать тип блокировки с помощью
l_type
. Возможные значения следующие:
F_RDLCK
Блокировка чтения. Для применения блокировки чтения файл должен быть открыт для чтения.
F_WRLCK
Блокировка записи. Для применения блокировки записи файл должен быть открыт для записи.
F_UNLCK
Освобождение предыдущей блокировки.
Таким образом, полная спецификация блокировки включает установку в структуре
struct flock
значений четырех полей: трех для указания блокируемой области и четвертого для описания нужного типа блока.
Значение
F_UNLCK
для l_type
снимает блокировку. В общем, это простейший способ снять те самые блоки, которые были установлены ранее, но можно «расщепить» блок, освободив диапазон байтов в середине ранее установленного более крупного блока. Например:
struct employee { /* что угодно */ }; /* Описание сотрудника */
struct flock lock; /* Структура блока */
...
/* Заблокировать сотрудников 6-8 */
lock.l_whence = SEEK_SET; /* Абсолютное положение */
lock.l_start = 5 * sizeof(struct employee); /* Начало 6-й структуры */
lock.l_len = sizeof(struct employee) * 3; /* Заблокировать 3 записи */
/* ...установка блокировки (см. следующий раздел)... */
/* Освобождение записи 7: предыдущий блок расщепляется на два: */
lock.l_whence = SEEK_SET; /* Абсолютное положение */
lock.l_start = 6 * sizeof(struct employee); /* Начало 7-й структуры */
lock.l_len = sizeof(struct employee) * 1; /* Разблокирование 1-й записи */
/* ...снятие блокировки (см. следующий раздел)... */
14.2.2.2. Установка и снятие блокировок
После заполнения структуры
struct flock
следующим шагом является запрос блокировки. Этот шаг осуществляется с помощью соответствующего значения аргумента cmd
функции fcntl()
:
F_GETLK
Узнать, можно ли установить блокировку.
F_SETLK
Установить или снять блокировку.
F_SETLKW
Установить блокировку, подождав, пока это будет возможным.
Команда
F_GETLK
является командой «Мама, можно мне?» Она осведомляется, доступна ли описанная struct flock
блокировка. Если она доступна, блокировка не устанавливается; вместо этого операционная система изменяет поле l_type
на F_UNLCK
. Другие поля остаются без изменений.
Если блокировка недоступна, операционная система заполняет различные поля сведениями, описывающими уже установленные блокировки, которые препятствуют установке новой. В этом случае
l_pid
содержит PID процесса, владеющего соответствующей блокировкой.[152] Если блокировка уже установлена, нет другого выбора, кроме ожидания в течение некоторого времени и новой попытки установки блокировки или вывода сообщения об ошибке и отказа от дальнейших попыток.
Команда
F_SETLK
пытается установить указанную блокировку. Если fcntl()
возвращает 0, блокировка была успешно установлена. Если она возвращает -1, блокировку установил другой процесс. В этом случае в errno устанавливается либо EAGAIN
(попытайтесь снова позже) или EACCESS
(нет доступа). Возможны два значения, чтобы удовлетворить старым системам.
Команда
F_SETLKW
также пытается установить указанную блокировку. Она отличается от F_SETLK
тем, что будет ждать, пока установка блокировки не окажется возможной.
Выбрав соответствующее значение для аргумента
cmd
, передайте его в качестве второго аргумента fcntl()
вместе с указателем на заполненную структуру struct flock
в качестве третьего аргумента:
struct flock lock;
int fd;
/* ...открыть файл, заполнить struct flock... */
if (fcntl(fd, F_SETLK, &lock) < 0) {
/* Установить не удалось, попытаться восстановиться */
}
Функция
lockf()
[153] предоставляет альтернативный способ установки блокировки в текущем положении файла.
#include /* XSI */
int lockf(int fd, int cmd, off_t len);
Дескриптор файла
fd
должен быть открыт для записи. len
указывает число блокируемых байтов: от текущего положения (назовем его pos
) до pos + len
байтов, если len
положительно, или от pos - len
до pos - 1
, если len отрицательно. Команды следующие:
F_LOCK
Устанавливает исключительную блокировку диапазона. Вызов блокируется до тех пор, пока блокировка диапазона не станет возможной.
F_TLOCK
Пытается установить блокировку. Это похоже на F_LOCK
, но если блокировка недоступна, F_TLOCK
возвращает ошибку.
F_ULOCK
Разблокирует указанный раздел. Это может вызвать расщепление блокировки, как описано выше.
F_TEST
Проверяет, доступна ли блокировка. Если доступна, возвращает 0 и устанавливает блокировку. В противном случае возвращает -1 и устанавливает в errno
EACCESS
.
Возвращаемое значение равно 0 в случае успеха и -1 при ошибке, с соответствующим значением в
errno
. Возможные значения ошибок включают:
EAGAIN
Файл заблокирован, для F_TLOCK
или F_TEST
.
EDEADLK
Для F_TLOCK
эта операция создала бы тупик.[154]
ENOLCK
Операционная система не смогла выделить блок.
Полезна комбинация
F_TLOCK
и EDEADLK
: если вы знаете, что тупик не может возникнуть никогда, используйте F_LOCK
. В противном случае, стоит обезопасить себя и использовать F_TLOCK
. Если блокировка доступна, она осуществляется, но если нет, у вас появляется возможность восстановления вместо блокирования в ожидании, возможно, навечно.
Завершив работу с заблокированным участком, его следует освободить. Для
fcntl()
возьмите первоначальную struct lock
, использованную для блокирования, и измените поле l_type
на F_UNLCK
. Затем используйте F_SETLK
в качестве аргумента cmd
:
lock.l_whence = ... ; /* Как раньше */
lock.l_start = ... ; /* Как раньше */
lock.l_len = ... ; /* Как раньше */
lock.l_type = F_UNLCK; /* Разблокировать */
if (fcntl(fd, F_SETLK, &lock) < 0) {
/* обработать ошибку */
}
/* Блокировка была снята */
Код, использующий
lockf()
, несколько проще. Для краткости мы опустили проверку ошибок:
off_t curpos, len;
curpos = lseek(fd, (off_t)0, SEEK_CUR); /* Получить текущее положение */
len = ... ; / * Установить соответствующее число блокируемых байтов */
lockf(fd, F_LOCK, len); / * Осуществить блокировку */
/* ...здесь использование заблокированного участка... */
lseek(fd, curpos, SEEK_SET); / * Вернуться к началу блокировки */
lockf(fd, F_ULOCK, len); /* Разблокировать файл */
Если вы не освободите блокировку явным образом, операционная система сделает это за вас в двух случаях. Первый случай, когда процесс завершается (либо при возвращении из
main()
, либо с использованием функции exit()
, которую мы рассматривали в разделе 9.1.5.1 «Определение статуса завершения процесса»). Другим случаем является вызов close()
с дескриптором файла: больше об этом в следующем разделе.
14.2.2.3. Предостережения по поводу блокировок
Имеется несколько предостережений, о которых нужно знать при блокировках файлов:
• Как описано ранее, вспомогательная блокировка является именно этим. Не взаимодействующий процесс может делать все, что хочет, за спиной (так сказать) процесса, осуществляющего блокировку.
• Эти вызовы не следует использовать в сочетании с библиотекой
. Эта библиотека осуществляет свое собственное буферирование. Хотя вы можете получить с помощью fileno()
дескриптор нижележащего файла, действительное положение в файле может быть не там, где вы думаете. В общем, стандартная библиотека ввода/вывода не понимает блокировок файлов.
• Держите в уме, что блокировки после
fork
не наследуются порожденными процессами, но они остаются на своем месте после exec
.
• Вызов
close()
с любым открытым для файла дескриптором удаляет все блокировки файла процессом, даже если другие дескрипторы для файла остаются открытыми.
То, что
close()
работает таким образом, является неудачным, но поскольку так была реализована первоначальная блокировка в fcntl()
, POSIX ее стандартизует. Стандартизация такого поведения позволяет избежать порчи существующего кода для Unix.
14.2.3. Блокирование BSD: flock()
4.2 BSD представило свой собственный механизм блокировки,
flock()
[155]. Функция объявлена следующим образом:
#include /* Обычный */
int flock(int fd, int operation);
Дескриптор
fd
представляет открытый файл. Имеются следующие операции:
LOCK_SH
Создает совместную блокировку. Может быть несколько совместных блокировок.
LOCK_EX
Создает исключительную блокировку. Может быть лишь одна такая блокировка.
LOCK_UN
Удаляет предыдущую блокировку.
LOCK_NB
При использовании побитового ИЛИ с LOCK_SH
или LOCK_EX
позволяет избежать блокирования функции, если блокировка файла невозможна.
По умолчанию запросы блокировки файла будут блокировать функцию (не давать ей вернуться), если существует конкурирующая блокировка. Запрашивающая функция возвращается, когда конкурирующая блокировка файла снимается и осуществляется запрошенная функцией блокировка файла. (Это предполагает, что по умолчанию имеется возможность возникновения тупика.) Чтобы попытаться заблокировать файл без блокирования функции, добавьте посредством побитового ИЛИ значение
LOCK_NB
к имеющемуся значению operation
.
Отличительными моментами
flock()
являются следующие:
• Блокировка с помощью
flock()
является вспомогательной; программа, не использующая блокировку, может прийти и испортить без всяких сообщений об ошибках файл, заблокированный с помощью flock()
.
• Блокируется весь файл. Нет механизма для блокировки только части файла.
• То, как был открыт файл, не влияет на тип блокировки, который может быть использован. (Сравните это с
fcntl()
, при использовании которой файл должен быть открыт для чтения для получения блокировки чтения, или для записи для блокировки записи.)
• Несколько открытых для одного и того же файла дескрипторов используют совместную блокировку. Для удаления блокировки может использоваться любой из них. В отличие от
fcntl()
, когда нет явного разблокирования, блокировка не удаляется до тех пор, пока не будут закрыты все открытые дескрипторы файла.
• Процесс может иметь лишь одну блокировку файла с помощью
flock()
; последовательный вызов flock()
с двумя различными типами блокировок изменяет тип блокировки на новый.
• На системах GNU/Linux блокировки
flock()
совершенно независимы от блокировок fcntl()
. Многие коммерческие системы Unix реализуют flock()
в виде «оболочки» поверх fcntl()
, но их семантика различается.
Мы не рекомендуем использовать
flock()
в новых программах, поскольку ее семантика не такая гибкая и поскольку она не стандартизована POSIX. Поддержка ее в GNU/Linux осуществляется главным образом для обратной совместимости с программным обеспечением, написанным для старых систем BSD Unix.
ЗАМЕЧАНИЕ. Справочная страница GNU/Linux flock(2) предупреждает, что блокировки
flock()
не работают для смонтированных удаленных файлов. Блокировки fcntl()
работают, при условии, что у вас достаточно новая версия Linux и сервер NFS поддерживает блокировки файлов
14.2.4. Обязательная блокировка
Большинство коммерческих систем Unix поддерживают в дополнение к вспомогательной обязательную блокировку файлов. Обязательная блокировка работает лишь с
fcntl()
. Обязательная блокировка файла контролируется установками прав доступа файла, в частности, путем добавления к файлу бита setgid с помощью команды chmod
.
$ echo hello, world > myfile /* Создать файл */
$ ls -l myfile /* Отобразить права доступа */
-rw-r--r-- 1 arnold devel 13 Apr 3 17:11 myfile
$ chmod g+s myfile /* Добавить бит setgid */
$ ls -l myfile /* Показать новые права доступа */
-rw-r-Sr-- 1 arnold devel 13 Apr 3 17:11 myfile
Бит права на исполнение группой должен быть оставлен сброшенным.
S
показывает, что бит setgid установлен, но что бит права на исполнение — нет; если бы были установлены оба бита, была бы использована строчная буква s
.
Комбинация установленного бита setgid и сброшенного бита права на исполнение группой обычно бессмысленно. По этой причине, она была выбрана разработчиками System V для обозначения «использования обязательного блокирования». И в самом деле, добавления этого бита достаточно, чтобы заставить коммерческую систему Unix, такую как Solaris, использовать блокировку файлов.
На системах GNU/Linux несколько другая история. Для обязательных блокировок файл должен иметь установленный бит setgid, но этого одного недостаточно. Файловая система, содержащая файл, также должна быть смонтирована с опцией
mand
в команде mount
.
Мы уже рассмотрели файловые системы, разделы диска, монтирование и команду mount, главным образом, в разделе 8.1 «Монтирование и демонтирование файловых систем». Мы можем продемонстрировать обязательную блокировку с помощью небольшой программы и файловой системой для тестирования на гибком диске. Для начала, вот программа:
1 /* ch14-lockall.c --- Демонстрация обязательной блокировки. */
2
3 #include /* для fprintf(), stderr, BUFSIZ */
4 #include /* объявление errno */
5 #include /* для флагов open() */
6 #include /* объявление strerror() */
7 #include /* для ssize_t */
8 #include
9 #include /* для mode_t */
10
11 int
12 main(int argc, char **argv)
13 {
14 int fd;
15 int i, j;
16 mode_t rw_mode;
17 static char message[] = "hello, world\n";
18 struct flock lock;
19
20 if (argc != 2) {
21 fprintf(stderr, "usage: %s file\n", argv[0]);
22 exit(1);
23 }
24
25 rw_mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH; / * 0644 */
26 fd = open(argv[1], O_RDWR|O_TRUNC|O_CREAT|O_EXCL, rw_mode);
27 if (fd < 0) {
28 fprintf(stderr, "%s: %s: cannot open for read/write: %s\n",
29 argv[0], argv[1], strerror(errno));
30 (void)close(fd);
31 return 1;
32 }
33
34 if (write(fd, message, strlen(message)) != strlen(message)) {
35 fprintf(stderr, "%s: %s: cannot write: %s\n",
36 argv[0], argv[1], strerror(errno));
37 (void)close(fd);
38 return 1;
39 }
40
41 rw_mode |= S_ISGID; /* добавить бит обязательной блокировки */
42
43 if (fchmod(fd, rw_mode) < 0) {
44 fprintf(stderr, "%s: %s: cannot change mode to %o: %s\n",
45 argv[0], argv[1], rw_mode, strerror(errno));
46 (void)close(fd);
47 return 1;
48 }
49
50 /* заблокировать файл */
51 memset(&lock, '\0', sizeof(lock));
52 lock.l_whence = SEEK_SET;
53 lock.l_start = 0;
54 lock.l_len =0; /* блокировка всего файла */
55 lock.l_type = F_WRLCK; /* блокировка записи */
56
57 if (fcntl(fd, F_SETLK, &lock) < 0) {
58 fprintf(stderr, "%s: %s: cannot lock the file: %s\n",
59 argv[0], argv[1], strerror(errno));
60 (void)close(fd);
61 return 1;
62 }
63
64 pause();
65
66 (void)close(fd);
67
68 return 0;
69 }
Программа устанавливает права доступа и создает файл, указанный в командной строке (строки 25 и 26). Затем она записывает в файл некоторые данные (строка 34). Строка 41 добавляет к правам доступа бит setgid, а строка 43 изменяет их. (Системный вызов
fchmod()
обсуждался в разделе 5.5.2 «Изменение прав доступа: chmod()
и fchmod()
».)
Строки 51–55 устанавливают
struct flock
для блокировки всего файла, а затем блокировка осуществляется реально в строке 57. Выполнив блокировку, программа засыпает, используя системный вызов pause()
(см. раздел 10.7 «Сигналы для межпроцессного взаимодействия»). После этого программа закрывает дескриптор файла и завершается. Вот расшифровка с комментариями, демонстрирующая использование обязательной блокировки файлов:
$ fdformat /dev/fd0 /* Форматировать гибкий диск */
Double -sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.
Formatting ... done
Verifying ... done
$ /sbin/mke2fs /dev/fd0 /* Создать файловую систему Linux */
/* ...множество вывода опущено... */
$ su /* Стать root, чтобы использовать mount */
Password: /* Пароль не отображается */
# mount -t ext2 -о mand /dev/fd0 /mnt/floppy /* Смонтировать гибкий
диск, с возможностью блокировок */
# suspend /* Приостановить оболочку root */
[1]+ Stopped su
$ ch14-lockall /mnt/floppy/x & /* Фоновая программа */
[2] 23311 /* содержит блокировку */
$ ls -l /mnt/floppy/x /* Посмотреть файл */
-rw-r-Sr-- 1 arnold devel 13 Apr 6 14:23 /mnt/floppy/x
$ echo something > /mnt/floppy/x /* Попытаться изменить файл */
bash2: /mnt/floppy/x: Resource temporarily unavailable
/* Возвращается ошибка */
$ kill %2 /* Завершить программу с блокировкой */
$ /* Нажать ENTER */
[2]- Terminated ch14-lockall /mnt/floppy/x /* Программа завершена */
$ echo something > /mnt/floppy/x /* Новая попытка изменения работает */
$ fg /* Вернуться в оболочку root */
su
# umount /mnt/floppy /* Демонтировать гибкий диск */
# exit /* Работа с оболочкой root закончена */
$
Пока выполняется
ch14-lockall
, она владеет блокировкой. Поскольку это обязательная блокировка, перенаправления ввода/вывода оболочки завершаются неудачей. После завершения ch14-lockall
блокировки освобождаются, и перенаправление ввода/вывода достигает цели. Как упоминалось ранее, под GNU/Linux даже root
не может аннулировать обязательную блокировку файла.
Немного отклоняясь в сторону, гибкие диски представляют отличный испытательный стенд для изучения того, как использовать инструменты, работающие с файловыми системами. Если вы сделаете что-то, что разрушит данные на гибком диске, это вряд ли будет катастрофическим, тогда как экспериментирование с действующими разделами на обычных жестких дисках значительно более рискованно.
14.3. Более точное время
Системный вызов
time()
и тип time_t
представляют время в секундах в формате отсчета с начала Эпохи. Разрешения в одну секунду на самом деле недостаточно, сегодняшние машины быстры, и часто бывает полезно различать временные интервалы в долях секунды. Начиная с 4.2 BSD, Berkley Unix представил ряд системных вызовов, которые сделали возможным получение и использование времени в долях секунд. Эти вызовы доступны на всех современных системах Unix, включая GNU/Linux.
14.3.1. Время в микросекундах: gettimeofday()
Первой задачей является получение времени дня:
#include
int gettimeofday(struct timeval *tv, void *tz); /* определение POSIX, а не GLIBC */
gettimeofday()
позволяет получить время дня.[156] В случае успеха возвращается 0, при ошибке -1. Аргументы следующие:
struct timeval *tv
Этот аргумент является указателем на
struct timeval
, которая вскоре будет описана и в которую система помещает текущее время.
void *tz
Это аргумент больше не используется; он имеет тип
void*
, поэтому он всегда должен равняться NULL
. (Справочная страница описывает, для чего он использовался, а затем утверждает, что он устарел. Прочтите, если интересуетесь подробностями.)
Время представлено структурой
struct timeval
:
struct timeval {
long tv_sec; /* секунды */
long tv_usec; /* микросекунды */
};
Значение
tv_sec
представляет секунды с начала Эпохи; tv_usec
является числом микросекунд в секунде.
Справочная страница GNU/Linux gettimeofday(2) документирует также следующие макросы:
#define timerisset(tvp) ((tvp)->tv_sec || (tvp)->tv_usec)
#define timercmp(tvp, uvp, cmp) \
((tvp)->tv_sec cmp (uvp)->tv_sec || \
(tvp)->tv_sec == (uvp)->tv_sec && \
(tvp)->tv_usec cmp (uvp)->tv_usec)
#define timerclear(tvp) ((tvp)->tv_sec = (tvp)->tv_usec = 0)
Эти макросы работают со значениями
struct timeval*
; то есть указателями на структуры, и их использование должно быть очевидным из их названий и кода. Особенно интересен макрос timercmp()
: третьим аргументом является оператор сравнения для указания вида сравнения. Например, рассмотрим определение того, является ли одна struct timeval
меньше другой:
struct timeval t1, t2;
...
if (timercmp(&t1, & t2, <))
/* t1 меньше, чем t2 */
Макрос развертывается в
((&t1)->tv_sec < (&t2)->tv_sec || \
(&t1)->tv_sec == (&t2)->tv_sec && \
(&t1)->tv_usec < (&t2)->tv_usec)
Это значит: «если
t1.tv_sec
меньше, чем t2.tv_sec
, ИЛИ если они равны и t1.tv_usec
меньше, чем t2.tv_usec
, тогда…».
14.3.2. Файловое время в микросекундах: utimes()
В разделе 5.5.3 «Изменение временных отметок:
utime()
» был описан системный вызов utime()
для установки времени последнего обращения и изменения данного файла. Некоторые файловые системы хранят эти временные отметки с разрешением в микросекунды (или еще точнее). Такие системы предусматривают системный вызов utimes()
(обратите внимание на завершающую s в названии) для установки времени обращения к файлу и его изменения с точностью до микросекунд:
#include /* XSI */
int utimes(char *filename, struct timeval tvp[2]);
Аргумент
tvp
должен указывать на массив из двух структур struct timeval
, значения используются для времени доступа и изменения соответственно. Если tvp
равен NULL
, система использует текущее время дня.
POSIX обозначает ее как «традиционную» функцию, что означает, что она стандартизуется лишь для поддержки старого кода и не должна использоваться для новых приложений. Главная причина, пожалуй, в том, что нет определенного интерфейса для получения времени доступа и изменения файла в микросекундах;
struct stat
содержит лишь значения time_t
, а не значения struct timeval
.
Однако, как упоминалось в разделе 5.4.3 «Только Linux: указание файлового времени повышенной точности», Linux 2.6 (и более поздние версии) действительно предоставляет доступ к временным отметкам с разрешением в наносекунды при помощи функции
stat()
. Некоторые другие системы (такие, как Solaris) также это делают.[157] Таким образом, utimes()
полезнее, чем кажется на первый взгляд, и несмотря на ее «традиционный» статус, нет причин не использовать ее в своих программах.
14.3.3. Интервальные таймеры: setitimer()
и getitimer()
Функция
alarm()
(см. раздел 10.8.1 «Сигнальные часы: sleep()
, alarm()
и SIGALRM
») организует отправку сигнала SIGALRM
после истечения данного числа секунд. Ее предельным разрешением является одна секунда. Здесь также BSD 4.2 ввело функцию и три различных таймера, которые используют время в долях секунды.
Интервальный таймер подобен многократно использующимся сигнальным часам. Вы устанавливаете начальное время, когда он должен «сработать», а также как часто это должно впоследствии повторяться. Оба этих значения используют объекты
struct timeval
; т.е. они (потенциально) имеют разрешение в микросекундах. Таймер «срабатывает», доставляя сигнал; таким образом, нужно установить для таймера обработчик сигнала, желательно до установки самого таймера.
Существуют три различных таймера, описанных в табл. 14.2.
Таблица 14.2. Интервальные таймеры
Таймер
Сигнал
Функция
ITIMER_REAL
SIGALRM
Работает в реальном режиме
ITIMER_VIRTUAL
SIGVTALRM
Работает, когда процесс выполняется в режиме пользователя
ITIMER_PROF
SIGPROF
Работает, когда процесс выполняется в режиме пользователя или ядра.
Использование первого таймера,
ITIMER_REAL
, просто. Таймер работает в реальном времени, посылая SIGALRM
по истечении заданного количества времени. (Поскольку посылается SIGALRM
, нельзя смешивать вызовы setitimer()
с вызовами alarm()
, а смешивание их с вызовом sleep()
также опасно; см. раздел 10.8.1 «Сигнальные часы, sleep()
, alarm()
и SIGALRM
».)
Второй таймер,
ITIMER_VIRTUAL
, также довольно прост. Он действует, когда процесс исполняется, но лишь при выполнении кода пользователя (приложения) Если процесс заблокирован во время ввода/вывода, например, на диск, или, еще важнее, на терминал, таймер приостанавливается.
Третий таймер,
ITIMER_PROF
, более специализированный. Он действует все время, пока выполняется процесс, даже если операционная система делает что-нибудь для процесса (вроде ввода/вывода). В соответствии со стандартом POSIX, он «предназначен для использования интерпретаторами при статистическом профилировании выполнения интерпретируемых программ». Установив как для ITIMER_VIRTUAL
, так и для ITIMER_PROF
идентичные интервалы и сравнивая разницу времени срабатывания двух таймеров, интерпретатор может узнать, сколько времени проводится в системных вызовах для выполняющейся интерпретируемой программы[158]. (Как сказано, это довольно специализировано.) Двумя системными вызовами являются:
#include /* XSI */
int getitimer(int which, struct itimerval *value);
int setitimer(int which, const struct itimerval *value,
struct itimerval *ovalue);
Аргумент
which
является одной из перечисленных ранее именованных констант, указывающих таймер, getitimer()
заполняет struct itimerval
, на которую указывает value
, текущими установками данного таймера, setitimer()
устанавливает для данного таймера значение в value
. Если имеется ovalue
, функция заполняет ее текущим значением таймера. Используйте для ovalue NULL
, если не хотите беспокоиться о текущем значении. Обе функции возвращают в случае успеха 0 и -1 при ошибке, struct itimerval
состоит из двух членов struct timeval
:
struct itimerval {
struct timeval it_interval; /* следующее значение */
struct timeval it_value; /* текущее значение */
};
Прикладным программам не следует ожидать, что таймеры будут с точностью до микросекунд. Справочная страница getitimer(2) дает следующее объяснение:
Таймеры никогда не срабатывают раньше заданного времени, вместо этого срабатывая спустя небольшой постоянный интервал времени, зависящий от разрешения системного таймера (в настоящее время 10 мс). После срабатывания будет сгенерирован сигнал, а таймер будет сброшен. Если таймер срабатывает, когда процесс выполняется (для таймера
ITIMER_VIRT
это всегда верно), сигнал будет доставлен немедленно после создания. В противном случае, доставка будет сдвинута на небольшой промежуток времени, зависящий от загрузки системы.
Из этих трех таймеров
ITIMER_REAL
кажется наиболее полезным. Следующая программа, ch14-timers.c
, показывает, как читать данные с терминала, но с тайм-аутом, чтобы программа не зависала на бесконечное время, ожидая ввода:
1 /* ch14-timers.c --- демонстрация интервальных таймеров */
2
3 #include
4 #include
5 #include
6 #include
7
8 /* handler --- обрабатывает SIGALRM */
9
10 void handler(int signo)
11 {
12 static const char msg[] = "\n*** Timer expired, you lose ***\n";
13
14 assert(signo == SIGALRM);
15
16 write(2, msg, sizeof(msg) - 1);
17 exit(1);
18 }
19
20 /* main --- установить таймер, прочесть данные с тайм-аутом */
21
22 int main(void)
23 {
24 struct itimerval tval;
25 char string[BUFSIZ];
26
27 timerclear(&tval.it_interval); /* нулевой интервал означает не сбрасывать таймер */
28 timerclear(&tval.it_value);
29
30 tval.it_value.tv_sec = 10; /* тайм-аут 10 секунд */
31
32 (void)signal(SIGALRM, handler);
33
34
35 printf("You have ten seconds to enter\nyour name, rank, and serial number: ");
36 (void)setitimer(ITIMER_REAL, &tval, NULL);
37 if (fgets(string, sizeof string, stdin) != NULL) {
38 (void)setitimer(ITIMER_REAL, NULL, NULL); /* выключить таймер */
39 /* обработать оставшиеся данные, вывод диагностики для иллюстрации */
40 printf("I'm glad you are being cooperative.\n");
41 } else
42 printf("\nEOF, eh? We won't give up so easily'\n");
43
44 exit(0);
45 }
Строки 10–18 представляют обработчик сигнала для
SIGALRM
; вызов assert()
гарантирует, что обработчик сигнала был установлен соответствующим образом. Тело обработчика выводит сообщение и выходит, но оно может делать что-нибудь более подходящее для крупномасштабной программы.
В функции
main()
строки 27–28 очищают два члена struct timeval
структуры struct itimerval.tval
. Затем строка 30 устанавливает тайм-аут в 10 секунд. Установка tval.it_interval
в 0 означает, что нет повторяющегося сигнала; он срабатывает лишь однажды. Строка 32 устанавливает обработчик сигнала, а строка 34 выводит приглашение.
Строка 36 устанавливает таймер, а строки 37–42 выводят соответствующие сообщения, основываясь на действиях пользователя. Реальная программа выполняла бы в этот момент свою задачу. Важно здесь обратить внимание на строку 38, которая отменяет таймер, поскольку были введены действительные данные.
ЗАМЕЧАНИЕ. Между строками 37 и 38 имеется намеренное состояние гонки. Все дело в том, что если пользователь не вводит строку в течение отведенного таймером времени, будет доставлен сигнал, и обработчик сигнала выведет сообщение «you lose».
Вот три успешных запуска программы:
$ ch14-timers /* Первый запуск, ничего не вводится */
You have ten seconds to enter
your name, rank, and serial number:
*** Timer expired, you lose ***
$ ch14-timers /* Второй запуск, ввод данных */
You have ten seconds to enter
your name, rank, and serial number: Jamas Kirk, Starfleet Captain, 1234
I'm glad you are being cooperative.
$ ch14-timers /* Третий запуск, ввод EOF (^D) */
You have ten seconds to enter
your name, rank, and serial number: ^D
EOF, eh? We won't give up so easily!
POSIX оставляет неопределенным, как интервальные таймеры взаимодействуют с функцией
sleep()
, если вообще взаимодействуют. GLIBC не использует для реализации sleep()
функцию alarm()
, поэтому на системах GNU/Linux sleep()
не взаимодействует с интервальным таймером. Однако, для переносимых программ, вы не можете делать такое предположение.
14.3.4. Более точные паузы: nanosleep()
Функция
sleep()
(см. раздел 10.8.1 «Сигнальные часы: sleep()
, alarm()
и SIGALRM
») дает программе возможность приостановиться на указанное число секунд. Но, как мы видели, она принимает лишь целое число секунд, что делает невозможным задержки на короткие периоды, она потенциально может также взаимодействовать с обработчиками SIGALRM
. Функция nanosleep()
компенсирует эти недостатки:
#include /* POSIX ТМР */
int nanosleep(const struct timespec *req, struct timespec *rem);
Эта функция является частью необязательного расширения POSIX «Таймеры» (TMR). Два аргумента являются запрошенным временем задержки и оставшимся числом времени в случае раннего возвращения (если
rem
не равен NULL
). Оба являются значениями struct timespec
:
struct timespec {
time_t tv_sec; /* секунды */
long tv_nsec; /* наносекунды */
};
Значение
tv_nsec
должно быть в диапазоне от 0 до 999 999 999. Как и в случае со sleep()
, время задержки может быть больше запрошенного в зависимости оттого, когда и как ядро распределяет время для исполнения процессов.
В отличие от
sleep()
, nanosleep()
не взаимодействует ни с какими сигналами, делая ее более безопасной и более простой для использования.
Возвращаемое значение равно 0, если выполнение процесса было задержано в течение всего указанного времени. В противном случае оно равно -1, с
errno
, указывающим ошибку. В частности, если errno
равен EINTR
, nanosleep()
была прервана сигналом. В этом случае, если rem
не равен NULL
, struct timespec
, на которую она указывает, содержит оставшееся время задержки. Это облегчает повторный вызов nanosleep()
для продолжения задержки.
Хотя это выглядит немного странным, вполне допустимо использовать одну и ту же структуру для обоих параметров:
struct timespec sleeptime = /* что угодно */;
int ret;
ret = nanosleep(&sleeptime, &sleeptime);
struct timeval
и struct timespec
сходны друг с другом, отличаясь лишь компонентом долей секунд. Заголовочный файл GLIBC
определяет для их взаимного преобразования друг в друга два полезных макроса:
#include /* GLIBC */
void TIMEVAL_TO_TIMESPEC(struct timeval *tv, struct timespec *ts);
void TIMEPSEC_TO_TIMEVAL(struct timespec *ts, struct timeval *tv);
Вот они:
# define TIMEVAL_TO_TIMESPEC(tv, ts) { \
(ts)->tv_sec = (tv)->tv_sec; \
(ts)->tv_nsec = (tv)->tv_usec * 1000; \
}
# define TIMESPEC_TO_TIMEVAL(tv, ts) { \
(tv)->tv_sec = (ts)->tv_sec; \
(tv)->tv_usec = (ts)->tv_nsec / 1000; \
}
#endif
ЗАМЕЧАНИЕ. To, что некоторые системные вызовы используют микросекунды, а другие — наносекунды, в самом деле сбивает с толку. Причина этого историческая: микросекундные вызовы были разработаны на системах, аппаратные часы которых не имели более высокого разрешения, тогда как наносекундные вызовы были разработаны более недавно для систем со значительно более точными часами. C'est la vie. Почти все, что вы можете сделать, это держать под руками ваше руководство.
14.4. Расширенный поиск с помощью двоичных деревьев
В разделе 6.2 «Функции сортировки и поиска» мы представили функции для поиска и сортировки массивов. В данном разделе мы рассмотрим более продвинутые возможности.
14.4.1. Введение в двоичные деревья
Массивы являются почти простейшим видом структурированных данных. Их просто понимать и использовать. Хотя у них есть недостаток, заключающийся в том, что их размер фиксируется во время компиляции. Таким образом, если у вас больше данных, чем помещается в массив, вам не повезло. Если у вас значительно меньше данных, чем размер массива, память расходуется зря. (Хотя на современных системах много памяти, подумайте об ограничениях программистов, пишущих программы для внедренных систем, таких, как микроволновые печи и мобильные телефоны. С другого конца спектра, подумайте о проблемах программистов, имеющих дело с огромными объемами ввода, таких, как прогнозирование погоды.
В области компьютерных наук были придуманы многочисленные динамические структуры данных, структуры, которые увеличивают и уменьшают свой размер по требованию и которые являются более гибкими, чем простые массивы, даже массивы, создаваемые и изменяемые динамически с помощью
malloc()
и realloc()
. Массивы при добавлении или удалении новых элементов требуется также повторно сортировать.
Одной из таких структур является дерево двоичного поиска, которое мы для краткости будем называть просто «двоичным деревом» («binary tree»). Двоичное дерево хранит элементы в сортированном порядке, вводя их в дерево в нужном месте при их появлении. Поиск по двоичному дереву также осуществляется быстро, время поиска примерно такое же, как при двоичном поиске в массиве. В отличие от массивов, двоичные деревья не нужно каждый раз повторно сортировать с самого начала при добавлении к ним элементов.
У двоичных деревьев есть один недостаток. В случае, когда вводимые данные уже отсортированы, время поиска в двоичном дереве сводится ко времени линейного поиска. Техническая сторона этого вопроса должна иметь дело с тем, как двоичные деревья управляются внутренне, что вскоре будет описано.
Теперь не избежать некоторой формальной терминологии, относящейся к структурам данных. На рис. 14.1 показано двоичное дерево. В информатике деревья изображаются, начиная сверху и расширяясь вниз. Чем ниже спускаетесь вы по дереву, тем больше его глубина. Каждый объект внутри дерева обозначается как вершина (node). На вершине дерева находится корень дерева с глубиной 0. Внизу находятся концевые вершины различной глубины. Концевые вершины отличают по тому, что у них нет ответвляющихся поддеревьев (subtrees), тогда как у внутренних вершин есть по крайней мере одно поддерево. Вершины с поддеревьями иногда называют родительскими (parent), они содержат порожденные вершины (children).
Рис. 14.1. Двоичное дерево
Чистые двоичные деревья отличаются тем, что каждая вершина содержит не более двух порожденных вершин. (Деревья с более чем двумя вершинами полезны, но не существенны для нашего обсуждения.) Порожденные вершины называются в этом случае левой и правой соответственно.
Деревья двоичного поиска отличаются еще и тем, что значения, хранящиеся в левой порожденной вершине, всегда меньше значения в родительской вершине, а значения, хранящиеся в правой порожденной вершине, всегда больше значения в родительской вершине. Это предполагает, что внутри дерева нет повторяющихся значений. Этот факт также объясняет, почему деревья не эффективны при работе с предварительно отсортированными данными: в зависимости от порядка сортировки, каждый новый элемент данных сохраняется либо только слева, либо только справа от находящегося впереди него элемента, образуя простой линейный список.
К двоичным деревьям применяют следующие операции:
Ввод
Добавление к дереву нового элемента.
Поиск
Нахождение элемента в дереве.
Удаление
Удаление элемента из дерева.
Прохождение (traversal)
Осуществление какой-либо операции с каждым хранящимся в дереве элементом. Прохождение дерева называют также обходом дерева (tree walk). Есть разнообразные способы «посещения» хранящихся в дереве элементов. Обсуждаемые здесь функции реализуют лишь один из таких способов. Мы дополнительно расскажем об этом позже.
14.4.2. Функции управления деревьями
Только что описанные операции соответствуют следующим функциям:
#include /* XSI */
void *tsearch(const void *key, void **rootp,
int (*compare)(const void*, const void*));
void *tfind(const void *key, const void **rootp,
int (*compare)(const void*, const void*));
void *tdelete(const void *key, void **rootp,
int (*compare)(const void*, const void*));
typedef enum { preorder, postorder, endorder, leaf } VISIT;
void twalk(const void *root,
void (*action)(const void *nodep, const VISIT which,
const int depth));
void tdestroy(void *root, void (*free_node)(void *nodep)); /* GLIBC*/
Эти функции были впервые определены для System V, а теперь формально стандартизованы POSIX. Они следуют структуре других, которые мы видели в разделе 6.2 «Функции сортировки и поиска»: использование указателей
void*
для указания на произвольные типы данных и предоставляемые пользователем функции сравнения для определения порядка. Как и для qsort()
и bsearch()
, функции сравнения должны возвращать отрицательное/нулевое/положительное значение, когда key
сравнивается со значением в вершине дерева.
14.4.3. Ввод элемента в дерево: tsearch()
Эти процедуры выделяют память для вершин дерева. Для их использования с несколькими деревьями нужно предоставить им указатель на переменную
void*
, в которую они заносят адрес корневой вершины. При создании нового дерева инициализируйте этот указатель в NULL
:
void *root = NULL; /* Корень нового дерева */
void *val; /* Указатель на возвращенные данные */
extern int my_compare(const void*, const void*); /* Функция сравнения */
extern char key[], key2[]; /* Значения для ввода в дерево */
val = tsearch(key, &root, my_compare);
/* Ввести в дерево первый элемент */
/* ...заполнить key2 другим значением. НЕ изменять корень... */
val = tsearch(key2, &root, my_compare);
/* Ввести в дерево последующий элемент */
Как показано, в переменной
root
должен быть NULL
лишь в первый раз, после чего нужно оставить ее как есть. При каждом последующем вызове tsearch()
использует ее для управления деревом.
Когда разыскиваемый
key
найден, как tsearch()
, так и tfind()
возвращают указатель на содержащую его вершину. Поведение функций различно, когда key
не найден: tfind()
возвращает NULL
, a tsearch()
вводит в дерево новое значение и возвращает указатель на него. Функции tsearch()
и tfind()
возвращают указатели на внутренние вершины дерева. Они могут использоваться в последующих вызовах в качестве значения root для работы с поддеревьями. Как мы вскоре увидим, значение key может быть указателем на произвольную структуру; он не ограничен символьной строкой, как можно было бы предположить из предыдущего примера.
Эти процедуры сохраняют лишь указатели на данные, использующиеся в качестве ключей. Соответственно это ваше дело управлять памятью для хранения значений данных, обычно с помощью
malloc()
.
ЗАМЕЧАНИЕ. Поскольку функции деревьев хранят указатели, тщательно позаботьтесь о том, чтобы не использовать
realloc()
для значений, которые были использованы в качестве ключей! realloc()
может переместить данные, вернув новый указатель, но процедуры деревьев все равно сохранят висящие (dangling) указатели на старые данные.
14.4.4. Поиск по дереву и использование возвращенного указателя: tfind()
и tsearch()
Функции
tfind()
и tsearch()
осуществляют поиск в двоичном дереве по данному ключу. Они принимают тот же самый набор аргументов: ключ для поиска key
. указатель на корень дерева, rootp
; и compare
, указатель на функцию сравнения. Обе функции возвращают указатель на вершину, которая соответствует key
.
Как именно использовать указатель, возвращенный
tfind()
и tsearch()
? Во всяком случае, на что именно он указывает? Ответ заключается в том, что он указывает на вершину в дереве. Это внутренний тип; вы не можете увидеть, как он определен. Однако, POSIX гарантирует, что этот указатель может быть приведен к указателю на указатель на что бы то ни было, что вы используете в качестве ключа. Вот обрывочный код для демонстрации, а затем мы покажем, как это работает:
struct employee { /* Из главы 6 */
char lastname[30];
char firstname[30];
long emp_id;
time_t start_date;
};
/* emp_name_id_compare --- сравнение по имени, затем no ID */
int emp_name_id_compare(const void *e1p, const void *e2p) {
/* ...также из главы 6, полностью представлено позже... */
}
struct employee key = { ... };
void *vp, *root;
struct employee *e;
/* ...заполнение данными... */
vp = tfind(&key, root, emp_name_id_compare);
if (vp != NULL) { /* it's there, use it */
e = *((struct employee**)vp); /* Получить хранящиеся в дереве данные */
/* использование данных в *е ... */
}
Как можно указатель на вершину использовать как указатель на указатель данных? Рассмотрим, как была бы реализована вершина двоичного дерева. В каждой вершине хранится по крайней мере указатель на элемент данных пользователя и указатели на потенциальные порожденные вершины справа и слева. Поэтому она должна выглядеть примерно так.
struct binary_tree {
void *user_data; /* Указатель на данные пользователя */
struct binary_tree *left; /* Порожденная вершина слева или NULL */
struct binary_tree *right; /* Порожденная вершина справа или NULL */
/* ...здесь возможны другие поля... */
} node;
С и C++ гарантируют, что поля внутри структуры располагаются в порядке возрастания адресов. Таким образом, выражение '
&node.left < &node.right
' истинно. Более того, адрес структуры является также адресом ее первого поля (другими словами, игнорируя проблемы типов, '&node == &node.user_data
').
Следовательно, концептуально '
е = *((struct employee**)vp);
' означает:
1.
vp
является void*
, то есть общим указателем. Это адрес внутренней вершины дерева, но это также адрес части вершины (скорее всего, другого void*
), которая указывает на данные пользователя.
2. '
(struct employee**)vp
' приводит адрес внутреннего указателя к нужному типу; он остается указателем на указатель, но в этот раз на struct employee
. Помните, что приведение одного типа указателя к другому не изменяют значения (паттерна битов); оно меняет лишь способ интерпретации компилятором значения для анализа типов.
3. '
*((struct employee**)vp)
' разыменовывает вновь созданный struct employee**
, возвращая годный к употреблению указатель struct employee*
.
4. '
е = *((struct employee**)vp)'
сохраняет это значение в е
для непосредственного использования позже.
Идея проиллюстрирована на рис. 14.2.
Рис. 14.2. Вершины дерева и их указатели
Для упрощения использования возвращенного указателя вы могли бы рассмотреть определение макроса:
#define tree_data(ptr, type)(*(type**)(ptr))
...
struct employee *e;
void *vp;
vp = tfind(&key, root, emp_name_id_compare);
if (vp != NULL) { /* it's there, use it */
e = tree_data(vp, struct employee);
/* использование сведений в *e ... */
}
14.4.5. Обход дерева: twalk()
Функция
twalk()
объявлена в
следующим образом:
typedef enum { preorder, postorder, endorder, leaf } VISIT;
void twalk(const void *root,
void (*action)(const void *nodep, const VISIT which,
const int depth));
Первый параметр является корнем дерева (не указателем на корень). Второй является указателем на функцию обратного вызова, которая вызывается с тремя аргументами, указателем на исследуемую вершину дерева; типом перечисления, указывающим, как осуществляется обход данной вершины; и целого, обозначающего глубину текущей вершины (корень находится на глубине 0, как объяснялось ранее).
Использование функции обратного вызова здесь такое же, как для
nftw()
(см. раздел 8.4.3.2 «Функция обратного вызова nftw()
»). Там функция обратного вызова вызывается для каждого объекта в файловой системе. Здесь функция обратного вызова вызывается для каждого объекта, хранящегося в дереве.
Есть несколько способов прохождения, или «обхода», двоичного дерева:
• Левая вершина, родительская вершина, правая вершина.
• Родительская вершина, левая вершина, правая вершина.
• Левая вершина, правая вершина, родительская вершина.
Функция GLIBC
twalk()
использует второй способ: сначала родительская вершина, затем левая, затем правая. Каждый раз при встрече с вершиной говорят, что она посещается.[159] В ходе посещения порожденной вершины функция должна посетить и родительскую. Соответственно, значения типа VISIT
указывают, на какой стадии произошла встреча с этой вершиной:
preorder
До посещения порожденных.
postorder
После посещения первой, но до посещения второй порожденной вершины.
endorder
После посещения обеих порожденных.
leaf
Эта вершина является концевой, не имеющей порожденных вершин.
ЗАМЕЧАНИЕ. Использованная здесь терминология не соответствует точно той, которая используется в формальных руководствах по структурированию данных. Там используются термины inorder, preorder и postorder для обозначения соответствующих трех перечисленных ранее способов прохождения дерева. Таким образом,
twalk()
использует прохождение по типу preorder
, но использует именованные константы preorder и т.д. для обозначения того, на какой стадии была посещена вершина. Это может сбивать с толку.
Следующая программа,
ch14-tsearch.c
, демонстрирует построение и обход дерева. Она повторно использует структуру struct employee
и функцию emp_name_id_compare()
из раздела 6.2 «Функции сортировки и поиска».
1 /* ch14-tsearch.c --- демонстрация управления деревом */
2
3 #include
4 #include
5 #include
6
7 struct employee {
8 char lastname[30];
9 char firstname[30];
10 long emp_id;
11 time_t start_date;
12 };
13
14 /* emp_name_id_compare --- сравнение по имени, затем no ID */
15
16 int emp_name_id_compare(const void *e1p, const void *e2p)
17 {
18 const struct employee *e1, *e2;
19 int last, first;
20
21 e1 = (const struct employee*)e1p;
22 e2 = (const struct employee*)e2p;
23
24 if ((last = strcmp(e1->lastname, e2->lastname)) != 0)
25 return last;
26
27 /* фамилии совпадают, проверить имена */
28 if ((first = strcmp(e1->firstname, e2->firstname)) != 0)
29 return first;
30
31 /* имена совпадают, проверить ID */
32 if (e1->emp_id < e2->emp_id)
33 return -1;
34 else if (e1->emp_id == e2->emp_id)
35 return 0;
36 else
37 return 1;
38 }
39
40 /* print_emp --- вывод структуры employee во время обхода дерева */
41
42 void print_emp(const void *nodep, const VISIT which, const int depth)
43 {
44 struct employee *e = *((struct employee**)nodep);
45
46 switch (which) {
47 case leaf:
48 case postorder:
49 printf("Depth: %d. Employee: \n", depth);
50 printf("\t%s, %s\t%d\t%s\n", e->lastname, e->firstname,
51 e->emp_id, ctime(&e->start_date));
52 break;
53 default:
54 break;
55 }
56 }
Строки 7–12 определяют
struct employee
, а строки 14–38 определяют emp_name_id_compare()
.
Строки 40–56 определяют
print_emp()
, функцию обратного вызова, которая выводит struct employee
наряду с глубиной дерева в текущей вершине. Обратите внимание на магическое приведение типа в строке 44 для получения указателя на сохраненные данные.
58 /* main --- демонстрация хранения данных в двоичном дереве */
59
60 int main(void)
61 {
62 #define NPRES 10
63 struct employee presidents[NPRES];
64 int i, npres;
65 char buf[BUFSIZ];
66 void *root = NULL;
67
68 /* Очень простой код для чтения данных: */
69 for (npres = 0; npres < NPRES && fgets(buf, BUFSIZ, stdin) != NULL;
70 npres++) {
71 sscanf(buf, "%s %s %ld %ld\n",
72 presidents[npres].lastname,
73 presidents[npres].firstname,
74 &presidents[npres].emp_id,
75 &presidents[npres].start_date);
76 }
77
78 for (i = 0; i < npres; i++)
79 (void)tsearch(&presidents[i], &root, emp_name_id_compare);
80
81 twalk(root, print_emp);
82 return 0;
83 }
Целью вывода дерева является вывод содержащихся в нем элементов в отсортированном порядке. Помните, что
twalk()
посещает промежуточные вершины по три раза и что левая вершина меньше родительской, тогда как правая больше. Таким образом, оператор switch
выводит сведения о вершине, лишь если which
равно leaf
, является концевой вершиной, или postorder
, что означает, что была посещена левая вершина, а правая еще не была посещена.
Используемые данные представляют собой список президентов, тоже из раздела 6.2 «Функции сортировки и поиска». Чтобы освежить вашу память, полями являются фамилия, имя, номер сотрудника и время начала работы в виде временной отметки в секундах с начала Эпохи:
$ cat presdata.txt
Bush George 43 980013600
Clinton William 42 727552800
Bush George 41 601322400
Reagan Ronald 40 348861600
Carter James 39 222631200
Данные сортируются на основе сначала фамилии, затем имени, а затем старшинства. При запуске[160] программа выдает следующий результат:
$ ch14-tsearch < presdata.txt
Depth: 1. Employee:
Bush, George 41 Fri Jan 20 13:00:00 1989
Depth: 0. Employee:
Bush, George 43 Sat Jan 20 13:00:00 2001
Depth: 2. Employee:
Carter, James 39 Thu Jan 20 13:00:00 1977
Depth: 1. Employee:
Clinton, William 42 Wed Jan 20 13:00:00 1993
Depth: 2. Employee:
Reagan, Ronald 40 Tue Jan 20 13:00:00 1981
14.4.6. Удаление вершины дерева и удаление дерева: tdelete()
и tdestroy()
Наконец, вы можете удалить элементы из дерева и, на системах GLIBC, удалить само дерево целиком:
void *tdelete(const void *key, void **rootp,
int (*compare)(const void*, const void*));
/* Расширение GLIBC, в POSIX нет: */
void tdestroy(void *root, void (*free_node)(void *nodep));
Аргументы для
tdelete()
те же, что и для tsearch()
: ключ, адрес корня дерева и функция сравнения. Если в дереве найден данный элемент, он удаляется, и tdelete()
возвращает указатель на родительскую вершину. В противном случае возвращается NULL
. С этим поведением следует обращаться в своем коде осмотрительно, если вам нужен первоначальный удаляемый элемент, например, для освобождения занимаемой им памяти.
struct employee *е, key; /* Объявления переменных */
void *vp, *root;
/* ...заполнить ключ для удаляемого из дерева элемента... */
vp = tfind(&key, root, emp_name_id_compare); /* Найти удаляемый элемент */
if (vp != NULL) {
e = *((struct employee**)vp); /* Преобразовать указатель */
free(e); /* Освободить память */
}
(void)tdelete(&key, &root, emp_name_id_compare); /* Теперь удалить его из дерева */
Хотя это и не указано в справочных страницах или стандарте POSIX, под GNU/Linux, если вы удаляете элемент, хранящийся в корневой вершине, возвращается значение новой корневой вершины. Для переносимого кода не следует полагаться на это поведение
Функция
tdestroy()
является расширением GLIBC. Она позволяет удалить дерево целиком. Первый аргумент является корнем дерева. Второй является указателем на функцию, которая освобождает данные, на которые указывает каждая вершина дерева. Если с этими данными ничего не надо делать (например, они хранятся в обычном массиве, как в примере нашей программы), эта функция ничего не должна делать. Не передавайте указатель NULL
! Это приведет к аварийной ситуации.
14.5. Резюме
• Иногда бывает необходимо выделить память, выровненную по определенной границе. Это осуществляет
posix_memalign()
. Ее возвращаемое значение отличается от большинства из рассмотренных в данной книге функций. memalign()
также выделяет выровненную память, но не все системы поддерживают освобождение памяти с помощью free()
.
• Блокирование файлов с помощью
fcntl()
предусматривает блокировку диапазонов, вплоть до блокирования отдельных байтов в файле. Блокировки чтения предотвращают запись в заблокированную область, а блокировки записи предотвращают чтение и запись другими процессами в заблокированную область. По умолчанию используется вспомогательная блокировка, и POSIX стандартизует лишь вспомогательную блокировку. Большинство современных систем Unix поддерживают обязательную блокировку, используя для файла бит setgid прав доступа, а также возможные дополнительные опции монтирования файловой системы.
• GNU/Linux функция
lockf()
действует в качестве оболочки вокруг блокировки POSIX с помощью fcntl()
; блокировки функции BSD flock()
совершенно независимы от блокировок fcntl()
. Блокировки BSD flock()
используются лишь для всего файла в целом и не работают на удаленных файловых системах. По этим причинам использование блокировки flock()
не рекомендуется.
•
gettimeofday
() получает время дня в виде пар (секунды, микросекунды) в struct timeval
. Эти значения используются utimes()
для обновления времени доступа и модификации файла. Системные вызовы gettimer()
и settimer()
используют пары struct timeva
l в struct itimerval
для создания интервальных таймеров — сигнальных часов, которые «срабатывают» в установленное время и продолжают срабатывать впоследствии с заданным интервалом. Три различных таймера обеспечивают контроль тех состояний, когда таймер продолжает действовать.
• Функция
nanosleep()
использует struct timespec
, которая указывает время в секундах и наносекундах, чтобы приостановить выполнение процесса в течение определенного интервала времени. У нее есть удачная особенность не взаимодействовать вообще с механизмами сигналов.
• Три API являются стандартным набором функций для хранения и поиска данных, которые сохраняют данные в двоичных деревьях в отсортированном виде. Эти три API очень гибкие, позволяя использовать множество деревьев и произвольные данные.
Упражнения
1. Напишите функцию
lockf()
, используя fcntl()
для осуществления блокировки.
2. Каталог
/usr/src/linux/Documentation
содержит набор файлов, которые описывают различные аспекты поведения операционной системы. Прочитайте файлы locks.txt
и mandatory.txt
, чтобы получить больше сведений об обработке Linux блокировок файлов.
3. Запустите на своей системе программу
ch14-lockall
без обязательной блокировки и посмотрите, сможете ли изменить файл-операнд.
4. Если у вас не-Linux система, поддерживающая обязательную блокировку, попробуйте исполнить на ней программу
ch14-lockall
.
5. Напишите функцию
strftimes()
следующего вида:
size_t strftimes(char *buf, size_t size, const char *format,
const struct timeval *tp);
Она должна вести себя подобно стандартной функции
strftime()
за тем исключением, что должна использовать %q
для обозначения «текущего числа микросекунд».
6. Используя только что написанную функцию
strftimes()
, напишите расширенную версию date, которая принимает форматирующую строку, начинающуюся с ведущего +
, и форматирует текущие дату и время (см. date(1)).
7. Обработка тайм-аута в
ch14-timers.c
довольно примитивна. Перепишите программу с использованием setjmp()
после вывода приглашения и longjmp()
из обработчика сигнала. Улучшает ли это структуру или ясность программы?
8. Мы заметили, что
ch14-timers.c
содержит намеренное состояние гонки. Предположим, пользователь вводит ответ в нужное время, но ch14-timers
приостановлена, прежде чем сигнал может быть отменен. Какой вызов вы сделаете, чтобы уменьшить размер проблемного окна?
9. Нарисуйте дерево, как показано в выводе
ch14-tsearch
в разделе 14.4.5 «Обход дерева: twalk()
».
10. Исследуйте файл
/usr/share/dict/words
на системе GNU/Linux. (Это словарь проверки правописания для spell
; на различных системах он может находиться в разных местах.) В файле слова размешены в отсортированном порядке, по одному в строке.
Для начала используйте программу
awk
для создания нового списка в случайном порядке:
$ awk '{ list[$0]++ }
> END { for (i in list) print i }' /usr/share/dict/words > /tmp/wlist
Далее, напишите две программы. Каждая должна читать новый список и сохранять каждое прочитанное слово в дереве и массиве соответственно. Вторая программа должна использовать для сортировки массива
qsort()
, а для поиска — bsearch()
. Получите из дерева или массива слово 'gravy
'. Вычислите время работы двух программ, чтобы увидеть, какая быстрее. Вам может потребоваться заключить получение слова внутрь цикла, повторяющегося множество раз (скажем, 1000), чтобы получить достаточное для определения разницы время.
Используйте вывод
ps
, чтобы посмотреть, сколько памяти используют программы
11. Повторно запустите обе программы, использовав оригинальный отсортированный словарный файл, и посмотрите, как изменятся временные результаты (если они вообще изменятся).
В данной главе описываются несколько расширенных API. Они сходны по своей природе с описанными ранее в книге или предоставляют дополнительные возможности. Некоторые из них трудно было свободно обсуждать, пока не были освещены предварительные темы.
Порядок представления здесь соответствует порядку глав в первой половине книги. В другом отношении темы не связаны друг с другом. Мы освещаем следующие вопросы: динамическое выделение выровненной памяти; блокировку файлов; ряд функций, работающих со значениями долей секунды; и более развитый набор функций для сохранения и получения произвольных значений данных. Если не указано противное, все API в данной главе включены в стандарт POSIX.
14.1. Выделение выровненной памяти: posix_memalign()
и memalign()
posix_memalign()memalign()Для большинства задач отлично подходят стандартные процедуры выделения памяти —
malloc()realloc()#include int posix_memalign(void **memptr, size_t alignment, size_t size); /* POSIX ADV */void *memalign(size_t boundary, size_t size); /* Обычная */posix_memalign()errnovoid **memptrУказатель на переменную
void*free()size_t alignmentТребуемое выравнивание. Оно должно быть кратно
sizeof(void*)size_t sizeЧисло выделяемых байтов.
memalign()NULLboundarysizeТрадиционно выделенная
memalign()free()memalign()malloc()posix_memalign()14.2. Блокировка файлов
Современные системы Unix, включая GNU/Linux, дают вам возможность заблокировать часть файла или весь файл для чтения или записи. Подобно многим частям Unix API, которые были разработаны после V7, имеется несколько несовместимых способов осуществить блокировку файлов. Данный раздел рассматривает эти возможности.
14.2.1. Концепции блокировки файлов
Также, как замок на вашей двери предотвращает нежелательные проникновения в ваш дом, блокировка файла предотвращает доступ к данным в файле. Блокировка файлов была добавлена в Unix после разработки V7 (от которой происходят все современные системы Unix), и соответственно в течение некоторого времени в различных системах Unix были доступны и использовались несколько несовместимых механизмов блокировки файлов. Как в BSD Unix, так и в System V были собственные несочетающиеся вызовы для блокировки. В конечном счете POSIX формализовал способ осуществления блокировки файлов System V. К счастью, названия функций в System V и BSD были различны, так что GNU/Linux, в попытке угодить всем, поддерживает обе разновидности блокировок.
Табл. 14.1 суммирует различные виды блокировок.
Таблица 14.1. Функции блокировки файлов
| Источник | Функция | Диапазон | Весь файл | Чтение/запись | Вспомогательный | Обязательный |
|---|---|---|---|---|---|---|
| BSD | |
√ | √ | √ | ||
| POSIX | |
√ | √ | √ | √ | √ |
| POSIX | |
√ | √ | √ | √ | √ |
Имеются следующие аспекты блокировки файлов:
Блокировка записей
Блокировка записи является блокировкой части файла. Поскольку файлы Unix являются просто потоками байтов, было бы корректнее использовать термин блокировка диапазона (range lock), поскольку осуществляется блокировка диапазона байтов. Тем не менее, термин «блокировка записей» общеупотребительный.
Блокировка всего файла
Блокировка всего файла, как предполагает название, блокирует весь файл, даже если его размер меняется в блокированном состоянии. Интерфейс BSD предусматривает блокирование лишь всего файла. Для блокирования всего файла с использованием интерфейса POSIX указывают нулевую длину. Это интерпретируется особым образом как «весь файл».
Блокировка чтения
Блокировка чтения предотвращает запись в читаемую область. В файле может быть несколько заблокированных для чтения участков, даже в одной области файла, не мешающих друг другу, поскольку к данным осуществляется лишь доступ и они не изменяются.
Блокировка записи
Блокировка записи предоставляет исключительный доступ к записываемой области. Если эта область заблокирована также и для чтения, попытка получения блокировки записи либо блокируется, либо завершается неудачей в зависимости от запрошенного типа блокировки. После получения блокировки записи попытка получить блокировку чтения завершается неудачей.
Вспомогательная блокировка
Вспомогательная блокировка (advisory lock) тесно соответствует замку на двери. Говорят, «замки существуют для честных людей», что означает, что если кто-нибудь на самом деле захочет вломиться в ваш дом, он, возможно, найдет способ это сделать, несмотря на наличие замка в двери. То же и со вспомогательной блокировкой; она работает лишь тогда, когда тот, кто пытается получить доступ к заблокированному файлу, сначала пытается получить блокировку. Однако, программа может совершенно игнорировать вспомогательные блокировки и делать с файлом, что захочет (конечно, пока это разрешается правами допуска файла).
Обязательная блокировка
Обязательная блокировка является более строгой: когда установлена обязательная блокировка, ни один другой процесс не может получить доступ к заблокированному файлу. Любой процесс, который пытается игнорировать это, либо сам блокируется до снятия блокировки файла, либо его попытка завершится неудачей. (Под GNU/Linux по крайней мере это включает
rootВспомогательная блокировка достаточна для взаимодействующих программ, разделяющих индивидуальный файл, когда не предполагается использование этого файла ни одним другим приложением. Обязательная блокировка подходит в ситуации, когда избежание конфликта в использовании файла является критическим, как в коммерческих системах баз данных.
POSIX стандартизует лишь вспомогательную блокировку. Обязательная блокировка доступна на GNU/Linux, а также в ряде коммерческих систем Unix, но детали варьируют. Далее в данном разделе мы рассмотрим детали для GNU/Linux.
14.2.2. Блокировка POSIX: fcntl()
и lockf()
Системный вызов
fcntl()
(file control — управление файлом) используется для блокировки файла. (Другое использование fcntl()
было описано в разделе 9.4.3 «Управление атрибутами файла: fcntl()
».) Он объявлен следующим образом:
#include /* POSIX */
#include
int fcntl(int fd, int cmd); /* Not relevant for file locking */
int fcntl(int fd, int cmd, long arg); /* Not relevant for file locking */
int fcntl(int fd, int cmd, struct flock *lock);
Аргументы следующие:
fd
Дескриптор файла для открытого файла.
cmd
Одна или более именованных констант, определенных в
. Ниже они описаны более подробно.
lock
Указатель на struct flock
, описывающую нужный блок.
14.2.2.1. Описание блокировки
Прежде чем рассмотреть осуществление блокировки, давайте исследуем описание блокировки в операционной системе. Это делается при помощи структуры
struct flock
, которая описывает диапазон блокируемых байтов и вид нужной блокировки. Стандарт POSIX утверждает, что struct lock
содержит «по крайней мере» определенные члены. Это позволяет разработчикам предоставлять при желании дополнительные члены структуры. Из слегка отредактированной справочной страницы fcntl(3):
struct flock {
...
short l_type; /* Тип блокировки: F_RDLCK, F_WRLCK, F_UNLCK */
short l_whence; /* Как интерпретируется l_start:
SEEK_SET, SEEK_CUR, SEEK_END */
off_t l_start; /* Начальное блокируемое смещение */
off_t l_len; /* Число блокируемых байтов;
0 означает от начала до конца файла */
pid_t l_pid; /* PID блокирующего процесса (только F_GETLK) */
...
};
Поле
l_start
является смешением начального байта блокируемого участка. l_len
является длиной блокируемого участка, т. е. общим числом блокируемых байтов. l_whence
указывает место в файле, относительно которого отсчитывается l_start
, значения те же, что и для аргумента whence
функции lseek()
(см раздел 4.5 «Произвольный доступ: перемещения внутри файла»), отсюда и название поля. Эта структура самодостаточна: смещение l_start
и значение l_whence
не связаны с текущим файловым указателем для чтения или записи. Пример кода мог бы выглядеть таким образом:
struct employee { /* что угодно */ }; /* Описание сотрудника */
struct flock lock; /* Структура блока */
...
/* Заблокировать структуру для шестого сотрудника */
lock.l_whence = SEEK_SET; /* Абсолютное положение */
lock.l_start = 5 * sizeof(struct employee); /* Начало 6-й структуры */
lock.l_len = sizeof(struct employee); /* Блокировать одну запись */
Используя
SEEK_CUR
или SEEK_END
, вы можете заблокировать участки, начиная от текущего смещения в файле или относительно конца файла соответственно. Для этих двух случаев l_start
может быть отрицательным, пока абсолютное начало не меньше нуля. Таким образом, чтобы заблокировать последнюю запись в файле:
/* Заблокировать запись последнего сотрудника */
lock.l_whence = SEEK_END; /* Относительно EOF */
lock.l_start = -1 * sizeof (struct employee);
/* Начало последней структуры */
lock.l_len = sizeof(struct employee); /* Заблокировать одну запись */
Установка
l_len
в 0 является особым случаем. Он означает блокировку файла от начального положения, указанного с помощью l_start
и l_whence
, и до конца файла. Сюда входят также любые области за концом файла. (Другими словами, если заблокированный файл увеличивается в размере, область блокировки расширяется таким образом, чтобы продолжать охватывать весь файл.) Таким образом, блокирование всего файла является вырожденным случаем блокирования одной записи:
lock.l_whence = SEEK_SET; /* Абсолютное положение */
lock.l_start = 0; /* Начало файла */
lock.l_len = 0; /* До конца файла */
Справочная страница fnctl(3) имеет примечание:
POSIX 1003.1-2001 допускает отрицательные значения
l_len
. (И если это так, описываемый блоком интервал охватывает байты с l_start + l_len
вплоть до l_start - 1
включительно.) Однако, в этой ситуации системный вызов Linux для современных ядер возвращает EINVAL
.
(Мы заметили, что справочная страница относится к версиям ядер 2.4.x; стоит проверить текущую справочную страницу, если ваша система новее.)
Теперь, когда мы знаем, как описать где блокируется файл, мы можем описать тип блокировки с помощью
l_type
. Возможные значения следующие:
F_RDLCK
Блокировка чтения. Для применения блокировки чтения файл должен быть открыт для чтения.
F_WRLCK
Блокировка записи. Для применения блокировки записи файл должен быть открыт для записи.
F_UNLCK
Освобождение предыдущей блокировки.
Таким образом, полная спецификация блокировки включает установку в структуре
struct flock
значений четырех полей: трех для указания блокируемой области и четвертого для описания нужного типа блока.
Значение
F_UNLCK
для l_type
снимает блокировку. В общем, это простейший способ снять те самые блоки, которые были установлены ранее, но можно «расщепить» блок, освободив диапазон байтов в середине ранее установленного более крупного блока. Например:
struct employee { /* что угодно */ }; /* Описание сотрудника */
struct flock lock; /* Структура блока */
...
/* Заблокировать сотрудников 6-8 */
lock.l_whence = SEEK_SET; /* Абсолютное положение */
lock.l_start = 5 * sizeof(struct employee); /* Начало 6-й структуры */
lock.l_len = sizeof(struct employee) * 3; /* Заблокировать 3 записи */
/* ...установка блокировки (см. следующий раздел)... */
/* Освобождение записи 7: предыдущий блок расщепляется на два: */
lock.l_whence = SEEK_SET; /* Абсолютное положение */
lock.l_start = 6 * sizeof(struct employee); /* Начало 7-й структуры */
lock.l_len = sizeof(struct employee) * 1; /* Разблокирование 1-й записи */
/* ...снятие блокировки (см. следующий раздел)... */
14.2.2.2. Установка и снятие блокировок
После заполнения структуры
struct flock
следующим шагом является запрос блокировки. Этот шаг осуществляется с помощью соответствующего значения аргумента cmd
функции fcntl()
:
F_GETLK
Узнать, можно ли установить блокировку.
F_SETLK
Установить или снять блокировку.
F_SETLKW
Установить блокировку, подождав, пока это будет возможным.
Команда
F_GETLK
является командой «Мама, можно мне?» Она осведомляется, доступна ли описанная struct flock
блокировка. Если она доступна, блокировка не устанавливается; вместо этого операционная система изменяет поле l_type
на F_UNLCK
. Другие поля остаются без изменений.
Если блокировка недоступна, операционная система заполняет различные поля сведениями, описывающими уже установленные блокировки, которые препятствуют установке новой. В этом случае
l_pid
содержит PID процесса, владеющего соответствующей блокировкой.[152] Если блокировка уже установлена, нет другого выбора, кроме ожидания в течение некоторого времени и новой попытки установки блокировки или вывода сообщения об ошибке и отказа от дальнейших попыток.
Команда
F_SETLK
пытается установить указанную блокировку. Если fcntl()
возвращает 0, блокировка была успешно установлена. Если она возвращает -1, блокировку установил другой процесс. В этом случае в errno устанавливается либо EAGAIN
(попытайтесь снова позже) или EACCESS
(нет доступа). Возможны два значения, чтобы удовлетворить старым системам.
Команда
F_SETLKW
также пытается установить указанную блокировку. Она отличается от F_SETLK
тем, что будет ждать, пока установка блокировки не окажется возможной.
Выбрав соответствующее значение для аргумента
cmd
, передайте его в качестве второго аргумента fcntl()
вместе с указателем на заполненную структуру struct flock
в качестве третьего аргумента:
struct flock lock;
int fd;
/* ...открыть файл, заполнить struct flock... */
if (fcntl(fd, F_SETLK, &lock) < 0) {
/* Установить не удалось, попытаться восстановиться */
}
Функция
lockf()
[153] предоставляет альтернативный способ установки блокировки в текущем положении файла.
#include /* XSI */
int lockf(int fd, int cmd, off_t len);
Дескриптор файла
fd
должен быть открыт для записи. len
указывает число блокируемых байтов: от текущего положения (назовем его pos
) до pos + len
байтов, если len
положительно, или от pos - len
до pos - 1
, если len отрицательно. Команды следующие:
F_LOCK
Устанавливает исключительную блокировку диапазона. Вызов блокируется до тех пор, пока блокировка диапазона не станет возможной.
F_TLOCK
Пытается установить блокировку. Это похоже на F_LOCK
, но если блокировка недоступна, F_TLOCK
возвращает ошибку.
F_ULOCK
Разблокирует указанный раздел. Это может вызвать расщепление блокировки, как описано выше.
F_TEST
Проверяет, доступна ли блокировка. Если доступна, возвращает 0 и устанавливает блокировку. В противном случае возвращает -1 и устанавливает в errno
EACCESS
.
Возвращаемое значение равно 0 в случае успеха и -1 при ошибке, с соответствующим значением в
errno
. Возможные значения ошибок включают:
EAGAIN
Файл заблокирован, для F_TLOCK
или F_TEST
.
EDEADLK
Для F_TLOCK
эта операция создала бы тупик.[154]
ENOLCK
Операционная система не смогла выделить блок.
Полезна комбинация
F_TLOCK
и EDEADLK
: если вы знаете, что тупик не может возникнуть никогда, используйте F_LOCK
. В противном случае, стоит обезопасить себя и использовать F_TLOCK
. Если блокировка доступна, она осуществляется, но если нет, у вас появляется возможность восстановления вместо блокирования в ожидании, возможно, навечно.
Завершив работу с заблокированным участком, его следует освободить. Для
fcntl()
возьмите первоначальную struct lock
, использованную для блокирования, и измените поле l_type
на F_UNLCK
. Затем используйте F_SETLK
в качестве аргумента cmd
:
lock.l_whence = ... ; /* Как раньше */
lock.l_start = ... ; /* Как раньше */
lock.l_len = ... ; /* Как раньше */
lock.l_type = F_UNLCK; /* Разблокировать */
if (fcntl(fd, F_SETLK, &lock) < 0) {
/* обработать ошибку */
}
/* Блокировка была снята */
Код, использующий
lockf()
, несколько проще. Для краткости мы опустили проверку ошибок:
off_t curpos, len;
curpos = lseek(fd, (off_t)0, SEEK_CUR); /* Получить текущее положение */
len = ... ; / * Установить соответствующее число блокируемых байтов */
lockf(fd, F_LOCK, len); / * Осуществить блокировку */
/* ...здесь использование заблокированного участка... */
lseek(fd, curpos, SEEK_SET); / * Вернуться к началу блокировки */
lockf(fd, F_ULOCK, len); /* Разблокировать файл */
Если вы не освободите блокировку явным образом, операционная система сделает это за вас в двух случаях. Первый случай, когда процесс завершается (либо при возвращении из
main()
, либо с использованием функции exit()
, которую мы рассматривали в разделе 9.1.5.1 «Определение статуса завершения процесса»). Другим случаем является вызов close()
с дескриптором файла: больше об этом в следующем разделе.
14.2.2.3. Предостережения по поводу блокировок
Имеется несколько предостережений, о которых нужно знать при блокировках файлов:
• Как описано ранее, вспомогательная блокировка является именно этим. Не взаимодействующий процесс может делать все, что хочет, за спиной (так сказать) процесса, осуществляющего блокировку.
• Эти вызовы не следует использовать в сочетании с библиотекой
. Эта библиотека осуществляет свое собственное буферирование. Хотя вы можете получить с помощью fileno()
дескриптор нижележащего файла, действительное положение в файле может быть не там, где вы думаете. В общем, стандартная библиотека ввода/вывода не понимает блокировок файлов.
• Держите в уме, что блокировки после
fork
не наследуются порожденными процессами, но они остаются на своем месте после exec
.
• Вызов
close()
с любым открытым для файла дескриптором удаляет все блокировки файла процессом, даже если другие дескрипторы для файла остаются открытыми.
То, что
close()
работает таким образом, является неудачным, но поскольку так была реализована первоначальная блокировка в fcntl()
, POSIX ее стандартизует. Стандартизация такого поведения позволяет избежать порчи существующего кода для Unix.
fcntl()lockf()Системный вызов
fcntl()fcntl()fcntl()#include /* POSIX */ #include int fcntl(int fd, int cmd); /* Not relevant for file locking */int fcntl(int fd, int cmd, long arg); /* Not relevant for file locking */int fcntl(int fd, int cmd, struct flock *lock);Аргументы следующие:
fdcmdlockstruct flock14.2.2.1. Описание блокировки
Прежде чем рассмотреть осуществление блокировки, давайте исследуем описание блокировки в операционной системе. Это делается при помощи структуры
struct flockstruct lockstruct flock { ... short l_type; /* Тип блокировки: F_RDLCK, F_WRLCK, F_UNLCK */ short l_whence; /* Как интерпретируется l_start: SEEK_SET, SEEK_CUR, SEEK_END */ off_t l_start; /* Начальное блокируемое смещение */ off_t l_len; /* Число блокируемых байтов; 0 означает от начала до конца файла */ pid_t l_pid; /* PID блокирующего процесса (только F_GETLK) */ ...};Поле
l_startl_lenl_whencel_startwhencelseek()l_startl_whencestruct employee { /* что угодно */ }; /* Описание сотрудника */struct flock lock; /* Структура блока */.../* Заблокировать структуру для шестого сотрудника */lock.l_whence = SEEK_SET; /* Абсолютное положение */lock.l_start = 5 * sizeof(struct employee); /* Начало 6-й структуры */lock.l_len = sizeof(struct employee); /* Блокировать одну запись */Используя
SEEK_CURSEEK_ENDl_start/* Заблокировать запись последнего сотрудника */lock.l_whence = SEEK_END; /* Относительно EOF */lock.l_start = -1 * sizeof (struct employee); /* Начало последней структуры */lock.l_len = sizeof(struct employee); /* Заблокировать одну запись */Установка
l_lenl_startl_whencelock.l_whence = SEEK_SET; /* Абсолютное положение */lock.l_start = 0; /* Начало файла */lock.l_len = 0; /* До конца файла */Справочная страница fnctl(3) имеет примечание:
POSIX 1003.1-2001 допускает отрицательные значения
l_lenl_start + l_lenl_start - 1EINVAL(Мы заметили, что справочная страница относится к версиям ядер 2.4.x; стоит проверить текущую справочную страницу, если ваша система новее.)
Теперь, когда мы знаем, как описать где блокируется файл, мы можем описать тип блокировки с помощью
l_typeF_RDLCK F_WRLCK F_UNLCK Таким образом, полная спецификация блокировки включает установку в структуре
struct flockЗначение
F_UNLCKl_typestruct employee { /* что угодно */ }; /* Описание сотрудника */struct flock lock; /* Структура блока */.../* Заблокировать сотрудников 6-8 */lock.l_whence = SEEK_SET; /* Абсолютное положение */lock.l_start = 5 * sizeof(struct employee); /* Начало 6-й структуры */lock.l_len = sizeof(struct employee) * 3; /* Заблокировать 3 записи *//* ...установка блокировки (см. следующий раздел)... *//* Освобождение записи 7: предыдущий блок расщепляется на два: */lock.l_whence = SEEK_SET; /* Абсолютное положение */lock.l_start = 6 * sizeof(struct employee); /* Начало 7-й структуры */lock.l_len = sizeof(struct employee) * 1; /* Разблокирование 1-й записи *//* ...снятие блокировки (см. следующий раздел)... */14.2.2.2. Установка и снятие блокировок
После заполнения структуры
struct flockcmdfcntl()F_GETLK F_SETLK F_SETLKW Команда
F_GETLKstruct flockl_typeF_UNLCKЕсли блокировка недоступна, операционная система заполняет различные поля сведениями, описывающими уже установленные блокировки, которые препятствуют установке новой. В этом случае
l_pidКоманда
F_SETLKfcntl()EAGAINEACCESSКоманда
F_SETLKWF_SETLKВыбрав соответствующее значение для аргумента
cmdfcntl()struct flockstruct flock lock; int fd; /* ...открыть файл, заполнить struct flock... */ if (fcntl(fd, F_SETLK, &lock) < 0) { /* Установить не удалось, попытаться восстановиться */}Функция
lockf()#include /* XSI */ int lockf(int fd, int cmd, off_t len);Дескриптор файла
fdlenpospos + lenlenpos - lenpos - 1F_LOCK F_TLOCK F_LOCKF_TLOCKF_ULOCK F_TEST errnoEACCESSВозвращаемое значение равно 0 в случае успеха и -1 при ошибке, с соответствующим значением в
errnoEAGAINF_TLOCKF_TESTEDEADLKF_TLOCKENOLCKПолезна комбинация
F_TLOCKEDEADLKF_LOCKF_TLOCKЗавершив работу с заблокированным участком, его следует освободить. Для
fcntl()struct lockl_typeF_UNLCKF_SETLKcmdlock.l_whence = ... ; /* Как раньше */lock.l_start = ... ; /* Как раньше */lock.l_len = ... ; /* Как раньше */lock.l_type = F_UNLCK; /* Разблокировать */if (fcntl(fd, F_SETLK, &lock) < 0) { /* обработать ошибку */}/* Блокировка была снята */Код, использующий
lockf()off_t curpos, len;curpos = lseek(fd, (off_t)0, SEEK_CUR); /* Получить текущее положение */len = ... ; / * Установить соответствующее число блокируемых байтов */lockf(fd, F_LOCK, len); / * Осуществить блокировку *//* ...здесь использование заблокированного участка... */lseek(fd, curpos, SEEK_SET); / * Вернуться к началу блокировки */lockf(fd, F_ULOCK, len); /* Разблокировать файл */Если вы не освободите блокировку явным образом, операционная система сделает это за вас в двух случаях. Первый случай, когда процесс завершается (либо при возвращении из
main()exit()close()14.2.2.3. Предостережения по поводу блокировок
Имеется несколько предостережений, о которых нужно знать при блокировках файлов:
• Как описано ранее, вспомогательная блокировка является именно этим. Не взаимодействующий процесс может делать все, что хочет, за спиной (так сказать) процесса, осуществляющего блокировку.
• Эти вызовы не следует использовать в сочетании с библиотекой
fileno()• Держите в уме, что блокировки после
forkexec• Вызов
close()То, что
close()fcntl()
14.2.3. Блокирование BSD: flock()
flock()4.2 BSD представило свой собственный механизм блокировки,
flock()#include /* Обычный */ int flock(int fd, int operation);Дескриптор
fdLOCK_SH LOCK_EX LOCK_UN LOCK_NB LOCK_SHLOCK_EXПо умолчанию запросы блокировки файла будут блокировать функцию (не давать ей вернуться), если существует конкурирующая блокировка. Запрашивающая функция возвращается, когда конкурирующая блокировка файла снимается и осуществляется запрошенная функцией блокировка файла. (Это предполагает, что по умолчанию имеется возможность возникновения тупика.) Чтобы попытаться заблокировать файл без блокирования функции, добавьте посредством побитового ИЛИ значение
LOCK_NBoperationОтличительными моментами
flock()• Блокировка с помощью
flock()flock()• Блокируется весь файл. Нет механизма для блокировки только части файла.
• То, как был открыт файл, не влияет на тип блокировки, который может быть использован. (Сравните это с
fcntl()• Несколько открытых для одного и того же файла дескрипторов используют совместную блокировку. Для удаления блокировки может использоваться любой из них. В отличие от
fcntl()• Процесс может иметь лишь одну блокировку файла с помощью
flock()flock()• На системах GNU/Linux блокировки
flock()fcntl()flock()fcntl()Мы не рекомендуем использовать
flock()ЗАМЕЧАНИЕ. Справочная страница GNU/Linux flock(2) предупреждает, что блокировки
flock()fcntl()14.2.4. Обязательная блокировка
Большинство коммерческих систем Unix поддерживают в дополнение к вспомогательной обязательную блокировку файлов. Обязательная блокировка работает лишь с
fcntl()chmod$ echo hello, world > myfile /* Создать файл */$ ls -l myfile /* Отобразить права доступа */-rw-r--r-- 1 arnold devel 13 Apr 3 17:11 myfile$ chmod g+s myfile /* Добавить бит setgid */$ ls -l myfile /* Показать новые права доступа */-rw-r-Sr-- 1 arnold devel 13 Apr 3 17:11 myfileБит права на исполнение группой должен быть оставлен сброшенным.
SsКомбинация установленного бита setgid и сброшенного бита права на исполнение группой обычно бессмысленно. По этой причине, она была выбрана разработчиками System V для обозначения «использования обязательного блокирования». И в самом деле, добавления этого бита достаточно, чтобы заставить коммерческую систему Unix, такую как Solaris, использовать блокировку файлов.
На системах GNU/Linux несколько другая история. Для обязательных блокировок файл должен иметь установленный бит setgid, но этого одного недостаточно. Файловая система, содержащая файл, также должна быть смонтирована с опцией
mandmountМы уже рассмотрели файловые системы, разделы диска, монтирование и команду mount, главным образом, в разделе 8.1 «Монтирование и демонтирование файловых систем». Мы можем продемонстрировать обязательную блокировку с помощью небольшой программы и файловой системой для тестирования на гибком диске. Для начала, вот программа:
1 /* ch14-lockall.c --- Демонстрация обязательной блокировки. */23 #include /* для fprintf(), stderr, BUFSIZ */ 4 #include /* объявление errno */ 5 #include /* для флагов open() */ 6 #include /* объявление strerror() */ 7 #include /* для ssize_t */ 8 #include 9 #include /* для mode_t */ 1011 int12 main(int argc, char **argv)13 {14 int fd;15 int i, j;16 mode_t rw_mode;17 static char message[] = "hello, world\n";18 struct flock lock;1920 if (argc != 2) {21 fprintf(stderr, "usage: %s file\n", argv[0]);22 exit(1);23 }2425 rw_mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH; / * 0644 */26 fd = open(argv[1], O_RDWR|O_TRUNC|O_CREAT|O_EXCL, rw_mode);27 if (fd < 0) {28 fprintf(stderr, "%s: %s: cannot open for read/write: %s\n",29 argv[0], argv[1], strerror(errno));30 (void)close(fd);31 return 1;32 }3334 if (write(fd, message, strlen(message)) != strlen(message)) {35 fprintf(stderr, "%s: %s: cannot write: %s\n",36 argv[0], argv[1], strerror(errno));37 (void)close(fd);38 return 1;39 }4041 rw_mode |= S_ISGID; /* добавить бит обязательной блокировки */4243 if (fchmod(fd, rw_mode) < 0) {44 fprintf(stderr, "%s: %s: cannot change mode to %o: %s\n",45 argv[0], argv[1], rw_mode, strerror(errno));46 (void)close(fd);47 return 1;48 }4950 /* заблокировать файл */51 memset(&lock, '\0', sizeof(lock));52 lock.l_whence = SEEK_SET;53 lock.l_start = 0;54 lock.l_len =0; /* блокировка всего файла */55 lock.l_type = F_WRLCK; /* блокировка записи */5657 if (fcntl(fd, F_SETLK, &lock) < 0) {58 fprintf(stderr, "%s: %s: cannot lock the file: %s\n",59 argv[0], argv[1], strerror(errno));60 (void)close(fd);61 return 1;62 }6364 pause();6566 (void)close(fd);6768 return 0;69 }Программа устанавливает права доступа и создает файл, указанный в командной строке (строки 25 и 26). Затем она записывает в файл некоторые данные (строка 34). Строка 41 добавляет к правам доступа бит setgid, а строка 43 изменяет их. (Системный вызов
fchmod()chmod()fchmod()Строки 51–55 устанавливают
struct flockpause()$ fdformat /dev/fd0 /* Форматировать гибкий диск */Double -sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.Formatting ... doneVerifying ... done$ /sbin/mke2fs /dev/fd0 /* Создать файловую систему Linux *//* ...множество вывода опущено... */$ su /* Стать root, чтобы использовать mount */Password: /* Пароль не отображается */# mount -t ext2 -о mand /dev/fd0 /mnt/floppy /* Смонтировать гибкийдиск, с возможностью блокировок */# suspend /* Приостановить оболочку root */[1]+ Stopped su$ ch14-lockall /mnt/floppy/x & /* Фоновая программа */[2] 23311 /* содержит блокировку */$ ls -l /mnt/floppy/x /* Посмотреть файл */-rw-r-Sr-- 1 arnold devel 13 Apr 6 14:23 /mnt/floppy/x$ echo something > /mnt/floppy/x /* Попытаться изменить файл */bash2: /mnt/floppy/x: Resource temporarily unavailable /* Возвращается ошибка */$ kill %2 /* Завершить программу с блокировкой */$ /* Нажать ENTER */[2]- Terminated ch14-lockall /mnt/floppy/x /* Программа завершена */$ echo something > /mnt/floppy/x /* Новая попытка изменения работает */$ fg /* Вернуться в оболочку root */su# umount /mnt/floppy /* Демонтировать гибкий диск */# exit /* Работа с оболочкой root закончена */$Пока выполняется
ch14-lockallch14-lockallrootНемного отклоняясь в сторону, гибкие диски представляют отличный испытательный стенд для изучения того, как использовать инструменты, работающие с файловыми системами. Если вы сделаете что-то, что разрушит данные на гибком диске, это вряд ли будет катастрофическим, тогда как экспериментирование с действующими разделами на обычных жестких дисках значительно более рискованно.
14.3. Более точное время
Системный вызов
time()time_t
14.3.1. Время в микросекундах: gettimeofday()
gettimeofday()Первой задачей является получение времени дня:
#include int gettimeofday(struct timeval *tv, void *tz); /* определение POSIX, а не GLIBC */gettimeofday()struct timeval *tvЭтот аргумент является указателем на
struct timevalvoid *tzЭто аргумент больше не используется; он имеет тип
void*NULLВремя представлено структурой
struct timevalstruct timeval { long tv_sec; /* секунды */ long tv_usec; /* микросекунды */};Значение
tv_sectv_usecСправочная страница GNU/Linux gettimeofday(2) документирует также следующие макросы:
#define timerisset(tvp) ((tvp)->tv_sec || (tvp)->tv_usec)#define timercmp(tvp, uvp, cmp) \ ((tvp)->tv_sec cmp (uvp)->tv_sec || \ (tvp)->tv_sec == (uvp)->tv_sec && \ (tvp)->tv_usec cmp (uvp)->tv_usec)#define timerclear(tvp) ((tvp)->tv_sec = (tvp)->tv_usec = 0)Эти макросы работают со значениями
struct timeval*timercmp()struct timevalstruct timeval t1, t2;...if (timercmp(&t1, & t2, <)) /* t1 меньше, чем t2 */Макрос развертывается в
((&t1)->tv_sec < (&t2)->tv_sec || \(&t1)->tv_sec == (&t2)->tv_sec && \(&t1)->tv_usec < (&t2)->tv_usec)Это значит: «если
t1.tv_sect2.tv_sect1.tv_usect2.tv_usec
14.3.2. Файловое время в микросекундах: utimes()
utimes()В разделе 5.5.3 «Изменение временных отметок:
utime()utime()utimes()#include /* XSI */ int utimes(char *filename, struct timeval tvp[2]);Аргумент
tvpstruct timevaltvpNULLPOSIX обозначает ее как «традиционную» функцию, что означает, что она стандартизуется лишь для поддержки старого кода и не должна использоваться для новых приложений. Главная причина, пожалуй, в том, что нет определенного интерфейса для получения времени доступа и изменения файла в микросекундах;
struct stattime_tstruct timevalОднако, как упоминалось в разделе 5.4.3 «Только Linux: указание файлового времени повышенной точности», Linux 2.6 (и более поздние версии) действительно предоставляет доступ к временным отметкам с разрешением в наносекунды при помощи функции
stat()utimes()
14.3.3. Интервальные таймеры: setitimer()
и getitimer()
setitimer()getitimer()Функция
alarm()sleep()alarm()SIGALRMSIGALRMИнтервальный таймер подобен многократно использующимся сигнальным часам. Вы устанавливаете начальное время, когда он должен «сработать», а также как часто это должно впоследствии повторяться. Оба этих значения используют объекты
struct timevalСуществуют три различных таймера, описанных в табл. 14.2.
Таблица 14.2. Интервальные таймеры
| Таймер | Сигнал | Функция |
|---|---|---|
|
|
Работает в реальном режиме |
|
|
Работает, когда процесс выполняется в режиме пользователя |
|
|
Работает, когда процесс выполняется в режиме пользователя или ядра. |
Использование первого таймера,
ITIMER_REALSIGALRMSIGALRMsetitimer()alarm()sleep()sleep()alarm()SIGALRMВторой таймер,
ITIMER_VIRTUALТретий таймер,
ITIMER_PROFITIMER_VIRTUALITIMER_PROF#include /* XSI */ int getitimer(int which, struct itimerval *value);int setitimer(int which, const struct itimerval *value, struct itimerval *ovalue);Аргумент
whichgetitimer()struct itimervalvaluesetitimer()valueovalueovalue NULLstruct itimervalstruct timevalstruct itimerval { struct timeval it_interval; /* следующее значение */ struct timeval it_value; /* текущее значение */};Прикладным программам не следует ожидать, что таймеры будут с точностью до микросекунд. Справочная страница getitimer(2) дает следующее объяснение:
Таймеры никогда не срабатывают раньше заданного времени, вместо этого срабатывая спустя небольшой постоянный интервал времени, зависящий от разрешения системного таймера (в настоящее время 10 мс). После срабатывания будет сгенерирован сигнал, а таймер будет сброшен. Если таймер срабатывает, когда процесс выполняется (для таймера
ITIMER_VIRTИз этих трех таймеров
ITIMER_REALch14-timers.c1 /* ch14-timers.c --- демонстрация интервальных таймеров */23 #include 4 #include 5 #include 6 #include 78 /* handler --- обрабатывает SIGALRM */910 void handler(int signo)11 {12 static const char msg[] = "\n*** Timer expired, you lose ***\n";1314 assert(signo == SIGALRM);1516 write(2, msg, sizeof(msg) - 1);17 exit(1);18 }1920 /* main --- установить таймер, прочесть данные с тайм-аутом */2122 int main(void)23 {24 struct itimerval tval;25 char string[BUFSIZ];2627 timerclear(&tval.it_interval); /* нулевой интервал означает не сбрасывать таймер */28 timerclear(&tval.it_value);2930 tval.it_value.tv_sec = 10; /* тайм-аут 10 секунд */3132 (void)signal(SIGALRM, handler);333435 printf("You have ten seconds to enter\nyour name, rank, and serial number: ");36 (void)setitimer(ITIMER_REAL, &tval, NULL);37 if (fgets(string, sizeof string, stdin) != NULL) {38 (void)setitimer(ITIMER_REAL, NULL, NULL); /* выключить таймер */39 /* обработать оставшиеся данные, вывод диагностики для иллюстрации */40 printf("I'm glad you are being cooperative.\n");41 } else42 printf("\nEOF, eh? We won't give up so easily'\n");4344 exit(0);45 }Строки 10–18 представляют обработчик сигнала для
SIGALRMassert()В функции
main()struct timevalstruct itimerval.tvaltval.it_intervalСтрока 36 устанавливает таймер, а строки 37–42 выводят соответствующие сообщения, основываясь на действиях пользователя. Реальная программа выполняла бы в этот момент свою задачу. Важно здесь обратить внимание на строку 38, которая отменяет таймер, поскольку были введены действительные данные.
ЗАМЕЧАНИЕ. Между строками 37 и 38 имеется намеренное состояние гонки. Все дело в том, что если пользователь не вводит строку в течение отведенного таймером времени, будет доставлен сигнал, и обработчик сигнала выведет сообщение «you lose».
Вот три успешных запуска программы:
$ ch14-timers /* Первый запуск, ничего не вводится */You have ten seconds to enteryour name, rank, and serial number:*** Timer expired, you lose ***$ ch14-timers /* Второй запуск, ввод данных */You have ten seconds to enteryour name, rank, and serial number: Jamas Kirk, Starfleet Captain, 1234I'm glad you are being cooperative.$ ch14-timers /* Третий запуск, ввод EOF (^D) */You have ten seconds to enteryour name, rank, and serial number: ^DEOF, eh? We won't give up so easily!POSIX оставляет неопределенным, как интервальные таймеры взаимодействуют с функцией
sleep()sleep()alarm()sleep()
14.3.4. Более точные паузы: nanosleep()
nanosleep()Функция
sleep()sleep()alarm()SIGALRMSIGALRMnanosleep()#include /* POSIX ТМР */ int nanosleep(const struct timespec *req, struct timespec *rem);Эта функция является частью необязательного расширения POSIX «Таймеры» (TMR). Два аргумента являются запрошенным временем задержки и оставшимся числом времени в случае раннего возвращения (если
remNULLstruct timespecstruct timespec { time_t tv_sec; /* секунды */ long tv_nsec; /* наносекунды */};Значение
tv_nsecsleep()В отличие от
sleep()nanosleep()Возвращаемое значение равно 0, если выполнение процесса было задержано в течение всего указанного времени. В противном случае оно равно -1, с
errnoerrnoEINTRnanosleep()remNULLstruct timespecnanosleep()Хотя это выглядит немного странным, вполне допустимо использовать одну и ту же структуру для обоих параметров:
struct timespec sleeptime = /* что угодно */;int ret;ret = nanosleep(&sleeptime, &sleeptime);struct timevalstruct timespec#include /* GLIBC */ void TIMEVAL_TO_TIMESPEC(struct timeval *tv, struct timespec *ts);void TIMEPSEC_TO_TIMEVAL(struct timespec *ts, struct timeval *tv);Вот они:
# define TIMEVAL_TO_TIMESPEC(tv, ts) { \ (ts)->tv_sec = (tv)->tv_sec; \ (ts)->tv_nsec = (tv)->tv_usec * 1000; \}# define TIMESPEC_TO_TIMEVAL(tv, ts) { \ (tv)->tv_sec = (ts)->tv_sec; \ (tv)->tv_usec = (ts)->tv_nsec / 1000; \}#endifЗАМЕЧАНИЕ. To, что некоторые системные вызовы используют микросекунды, а другие — наносекунды, в самом деле сбивает с толку. Причина этого историческая: микросекундные вызовы были разработаны на системах, аппаратные часы которых не имели более высокого разрешения, тогда как наносекундные вызовы были разработаны более недавно для систем со значительно более точными часами. C'est la vie. Почти все, что вы можете сделать, это держать под руками ваше руководство.
14.4. Расширенный поиск с помощью двоичных деревьев
В разделе 6.2 «Функции сортировки и поиска» мы представили функции для поиска и сортировки массивов. В данном разделе мы рассмотрим более продвинутые возможности.
14.4.1. Введение в двоичные деревья
Массивы являются почти простейшим видом структурированных данных. Их просто понимать и использовать. Хотя у них есть недостаток, заключающийся в том, что их размер фиксируется во время компиляции. Таким образом, если у вас больше данных, чем помещается в массив, вам не повезло. Если у вас значительно меньше данных, чем размер массива, память расходуется зря. (Хотя на современных системах много памяти, подумайте об ограничениях программистов, пишущих программы для внедренных систем, таких, как микроволновые печи и мобильные телефоны. С другого конца спектра, подумайте о проблемах программистов, имеющих дело с огромными объемами ввода, таких, как прогнозирование погоды.
В области компьютерных наук были придуманы многочисленные динамические структуры данных, структуры, которые увеличивают и уменьшают свой размер по требованию и которые являются более гибкими, чем простые массивы, даже массивы, создаваемые и изменяемые динамически с помощью
malloc()realloc()Одной из таких структур является дерево двоичного поиска, которое мы для краткости будем называть просто «двоичным деревом» («binary tree»). Двоичное дерево хранит элементы в сортированном порядке, вводя их в дерево в нужном месте при их появлении. Поиск по двоичному дереву также осуществляется быстро, время поиска примерно такое же, как при двоичном поиске в массиве. В отличие от массивов, двоичные деревья не нужно каждый раз повторно сортировать с самого начала при добавлении к ним элементов.
У двоичных деревьев есть один недостаток. В случае, когда вводимые данные уже отсортированы, время поиска в двоичном дереве сводится ко времени линейного поиска. Техническая сторона этого вопроса должна иметь дело с тем, как двоичные деревья управляются внутренне, что вскоре будет описано.
Теперь не избежать некоторой формальной терминологии, относящейся к структурам данных. На рис. 14.1 показано двоичное дерево. В информатике деревья изображаются, начиная сверху и расширяясь вниз. Чем ниже спускаетесь вы по дереву, тем больше его глубина. Каждый объект внутри дерева обозначается как вершина (node). На вершине дерева находится корень дерева с глубиной 0. Внизу находятся концевые вершины различной глубины. Концевые вершины отличают по тому, что у них нет ответвляющихся поддеревьев (subtrees), тогда как у внутренних вершин есть по крайней мере одно поддерево. Вершины с поддеревьями иногда называют родительскими (parent), они содержат порожденные вершины (children).
Рис. 14.1. Двоичное дерево
Чистые двоичные деревья отличаются тем, что каждая вершина содержит не более двух порожденных вершин. (Деревья с более чем двумя вершинами полезны, но не существенны для нашего обсуждения.) Порожденные вершины называются в этом случае левой и правой соответственно.
Деревья двоичного поиска отличаются еще и тем, что значения, хранящиеся в левой порожденной вершине, всегда меньше значения в родительской вершине, а значения, хранящиеся в правой порожденной вершине, всегда больше значения в родительской вершине. Это предполагает, что внутри дерева нет повторяющихся значений. Этот факт также объясняет, почему деревья не эффективны при работе с предварительно отсортированными данными: в зависимости от порядка сортировки, каждый новый элемент данных сохраняется либо только слева, либо только справа от находящегося впереди него элемента, образуя простой линейный список.
К двоичным деревьям применяют следующие операции:
Ввод
Добавление к дереву нового элемента.
Поиск
Нахождение элемента в дереве.
Удаление
Удаление элемента из дерева.
Прохождение (traversal)
Осуществление какой-либо операции с каждым хранящимся в дереве элементом. Прохождение дерева называют также обходом дерева (tree walk). Есть разнообразные способы «посещения» хранящихся в дереве элементов. Обсуждаемые здесь функции реализуют лишь один из таких способов. Мы дополнительно расскажем об этом позже.
14.4.2. Функции управления деревьями
Только что описанные операции соответствуют следующим функциям:
#include /* XSI */ void *tsearch(const void *key, void **rootp,int (*compare)(const void*, const void*));void *tfind(const void *key, const void **rootp,int (*compare)(const void*, const void*));void *tdelete(const void *key, void **rootp,int (*compare)(const void*, const void*));typedef enum { preorder, postorder, endorder, leaf } VISIT;void twalk(const void *root,void (*action)(const void *nodep, const VISIT which,const int depth));void tdestroy(void *root, void (*free_node)(void *nodep)); /* GLIBC*/Эти функции были впервые определены для System V, а теперь формально стандартизованы POSIX. Они следуют структуре других, которые мы видели в разделе 6.2 «Функции сортировки и поиска»: использование указателей
void*qsort()bsearch()key
14.4.3. Ввод элемента в дерево: tsearch()
tsearch()Эти процедуры выделяют память для вершин дерева. Для их использования с несколькими деревьями нужно предоставить им указатель на переменную
void*NULLvoid *root = NULL; /* Корень нового дерева */void *val; /* Указатель на возвращенные данные */extern int my_compare(const void*, const void*); /* Функция сравнения */extern char key[], key2[]; /* Значения для ввода в дерево */val = tsearch(key, &root, my_compare); /* Ввести в дерево первый элемент *//* ...заполнить key2 другим значением. НЕ изменять корень... */val = tsearch(key2, &root, my_compare); /* Ввести в дерево последующий элемент */Как показано, в переменной
rootNULLtsearch()Когда разыскиваемый
keytsearch()tfind()keytfind()NULLtsearch()tsearch()tfind()Эти процедуры сохраняют лишь указатели на данные, использующиеся в качестве ключей. Соответственно это ваше дело управлять памятью для хранения значений данных, обычно с помощью
malloc()ЗАМЕЧАНИЕ. Поскольку функции деревьев хранят указатели, тщательно позаботьтесь о том, чтобы не использовать
realloc()realloc()
14.4.4. Поиск по дереву и использование возвращенного указателя: tfind()
и tsearch()
tfind()tsearch()Функции
tfind()tsearch()keyrootpcomparekeyКак именно использовать указатель, возвращенный
tfind()tsearch()struct employee { /* Из главы 6 */ char lastname[30]; char firstname[30]; long emp_id; time_t start_date;};/* emp_name_id_compare --- сравнение по имени, затем no ID */int emp_name_id_compare(const void *e1p, const void *e2p) { /* ...также из главы 6, полностью представлено позже... */}struct employee key = { ... };void *vp, *root;struct employee *e;/* ...заполнение данными... */vp = tfind(&key, root, emp_name_id_compare);if (vp != NULL) { /* it's there, use it */ e = *((struct employee**)vp); /* Получить хранящиеся в дереве данные */ /* использование данных в *е ... */}Как можно указатель на вершину использовать как указатель на указатель данных? Рассмотрим, как была бы реализована вершина двоичного дерева. В каждой вершине хранится по крайней мере указатель на элемент данных пользователя и указатели на потенциальные порожденные вершины справа и слева. Поэтому она должна выглядеть примерно так.
struct binary_tree { void *user_data; /* Указатель на данные пользователя */ struct binary_tree *left; /* Порожденная вершина слева или NULL */ struct binary_tree *right; /* Порожденная вершина справа или NULL *//* ...здесь возможны другие поля... */} node;С и C++ гарантируют, что поля внутри структуры располагаются в порядке возрастания адресов. Таким образом, выражение '
&node.left < &node.right&node == &node.user_dataСледовательно, концептуально '
е = *((struct employee**)vp);1.
vpvoid*void*2. '
(struct employee**)vpstruct employee3. '
*((struct employee**)vp)struct employee**struct employee*4. '
е = *((struct employee**)vp)'еИдея проиллюстрирована на рис. 14.2.
Рис. 14.2. Вершины дерева и их указатели
Для упрощения использования возвращенного указателя вы могли бы рассмотреть определение макроса:
#define tree_data(ptr, type)(*(type**)(ptr))...struct employee *e;void *vp;vp = tfind(&key, root, emp_name_id_compare);if (vp != NULL) { /* it's there, use it */ e = tree_data(vp, struct employee); /* использование сведений в *e ... */}
14.4.5. Обход дерева: twalk()
twalk()Функция
twalk()typedef enum { preorder, postorder, endorder, leaf } VISIT;void twalk(const void *root, void (*action)(const void *nodep, const VISIT which,const int depth));Первый параметр является корнем дерева (не указателем на корень). Второй является указателем на функцию обратного вызова, которая вызывается с тремя аргументами, указателем на исследуемую вершину дерева; типом перечисления, указывающим, как осуществляется обход данной вершины; и целого, обозначающего глубину текущей вершины (корень находится на глубине 0, как объяснялось ранее).
Использование функции обратного вызова здесь такое же, как для
nftw()nftw()Есть несколько способов прохождения, или «обхода», двоичного дерева:
• Левая вершина, родительская вершина, правая вершина.
• Родительская вершина, левая вершина, правая вершина.
• Левая вершина, правая вершина, родительская вершина.
Функция GLIBC
twalk()VISITpreorder postorder endorder leafЗАМЕЧАНИЕ. Использованная здесь терминология не соответствует точно той, которая используется в формальных руководствах по структурированию данных. Там используются термины inorder, preorder и postorder для обозначения соответствующих трех перечисленных ранее способов прохождения дерева. Таким образом,
twalk()preorderСледующая программа,
ch14-tsearch.cstruct employeeemp_name_id_compare()1 /* ch14-tsearch.c --- демонстрация управления деревом */23 #include 4 #include 5 #include 67 struct employee {8 char lastname[30];9 char firstname[30];10 long emp_id;11 time_t start_date;12 };1314 /* emp_name_id_compare --- сравнение по имени, затем no ID */1516 int emp_name_id_compare(const void *e1p, const void *e2p)17 {18 const struct employee *e1, *e2;19 int last, first;2021 e1 = (const struct employee*)e1p;22 e2 = (const struct employee*)e2p;2324 if ((last = strcmp(e1->lastname, e2->lastname)) != 0)25 return last;2627 /* фамилии совпадают, проверить имена */28 if ((first = strcmp(e1->firstname, e2->firstname)) != 0)29 return first;3031 /* имена совпадают, проверить ID */32 if (e1->emp_id < e2->emp_id)33 return -1;34 else if (e1->emp_id == e2->emp_id)35 return 0;36 else37 return 1;38 }3940 /* print_emp --- вывод структуры employee во время обхода дерева */4142 void print_emp(const void *nodep, const VISIT which, const int depth)43 {44 struct employee *e = *((struct employee**)nodep);4546 switch (which) {47 case leaf:48 case postorder:49 printf("Depth: %d. Employee: \n", depth);50 printf("\t%s, %s\t%d\t%s\n", e->lastname, e->firstname,51 e->emp_id, ctime(&e->start_date));52 break;53 default:54 break;55 }56 }Строки 7–12 определяют
struct employeeemp_name_id_compare()Строки 40–56 определяют
print_emp()struct employee58 /* main --- демонстрация хранения данных в двоичном дереве */5960 int main(void)61 {62 #define NPRES 1063 struct employee presidents[NPRES];64 int i, npres;65 char buf[BUFSIZ];66 void *root = NULL;6768 /* Очень простой код для чтения данных: */69 for (npres = 0; npres < NPRES && fgets(buf, BUFSIZ, stdin) != NULL;70 npres++) {71 sscanf(buf, "%s %s %ld %ld\n",72 presidents[npres].lastname,73 presidents[npres].firstname,74 &presidents[npres].emp_id,75 &presidents[npres].start_date);76 }7778 for (i = 0; i < npres; i++)79 (void)tsearch(&presidents[i], &root, emp_name_id_compare);8081 twalk(root, print_emp);82 return 0;83 }Целью вывода дерева является вывод содержащихся в нем элементов в отсортированном порядке. Помните, что
twalk()switchwhichleafpostorderИспользуемые данные представляют собой список президентов, тоже из раздела 6.2 «Функции сортировки и поиска». Чтобы освежить вашу память, полями являются фамилия, имя, номер сотрудника и время начала работы в виде временной отметки в секундах с начала Эпохи:
$ cat presdata.txtBush George 43 980013600Clinton William 42 727552800Bush George 41 601322400Reagan Ronald 40 348861600Carter James 39 222631200Данные сортируются на основе сначала фамилии, затем имени, а затем старшинства. При запуске[160] программа выдает следующий результат:
$ ch14-tsearch < presdata.txtDepth: 1. Employee:Bush, George 41 Fri Jan 20 13:00:00 1989Depth: 0. Employee:Bush, George 43 Sat Jan 20 13:00:00 2001Depth: 2. Employee:Carter, James 39 Thu Jan 20 13:00:00 1977Depth: 1. Employee:Clinton, William 42 Wed Jan 20 13:00:00 1993Depth: 2. Employee:Reagan, Ronald 40 Tue Jan 20 13:00:00 1981
14.4.6. Удаление вершины дерева и удаление дерева: tdelete()
и tdestroy()
tdelete()tdestroy()Наконец, вы можете удалить элементы из дерева и, на системах GLIBC, удалить само дерево целиком:
void *tdelete(const void *key, void **rootp,int (*compare)(const void*, const void*));/* Расширение GLIBC, в POSIX нет: */void tdestroy(void *root, void (*free_node)(void *nodep));Аргументы для
tdelete()tsearch()tdelete()NULLstruct employee *е, key; /* Объявления переменных */void *vp, *root;/* ...заполнить ключ для удаляемого из дерева элемента... */vp = tfind(&key, root, emp_name_id_compare); /* Найти удаляемый элемент */if (vp != NULL) { e = *((struct employee**)vp); /* Преобразовать указатель */ free(e); /* Освободить память */}(void)tdelete(&key, &root, emp_name_id_compare); /* Теперь удалить его из дерева */Хотя это и не указано в справочных страницах или стандарте POSIX, под GNU/Linux, если вы удаляете элемент, хранящийся в корневой вершине, возвращается значение новой корневой вершины. Для переносимого кода не следует полагаться на это поведение
Функция
tdestroy()NULL14.5. Резюме
• Иногда бывает необходимо выделить память, выровненную по определенной границе. Это осуществляет
posix_memalign()memalign()free()• Блокирование файлов с помощью
fcntl()• GNU/Linux функция
lockf()fcntl()flock()fcntl()flock()flock()•
gettimeofdaystruct timevalutimes()gettimer()settimer()struct timevastruct itimerval• Функция
nanosleep()struct timespec• Три API являются стандартным набором функций для хранения и поиска данных, которые сохраняют данные в двоичных деревьях в отсортированном виде. Эти три API очень гибкие, позволяя использовать множество деревьев и произвольные данные.
Упражнения
1. Напишите функцию
lockf()fcntl()2. Каталог
/usr/src/linux/Documentationlocks.txtmandatory.txt3. Запустите на своей системе программу
ch14-lockall4. Если у вас не-Linux система, поддерживающая обязательную блокировку, попробуйте исполнить на ней программу
ch14-lockall5. Напишите функцию
strftimes()size_t strftimes(char *buf, size_t size, const char *format, const struct timeval *tp);Она должна вести себя подобно стандартной функции
strftime()%q6. Используя только что написанную функцию
strftimes()+7. Обработка тайм-аута в
ch14-timers.csetjmp()longjmp()8. Мы заметили, что
ch14-timers.cch14-timers9. Нарисуйте дерево, как показано в выводе
ch14-tsearchtwalk()10. Исследуйте файл
/usr/share/dict/wordsspellДля начала используйте программу
awk$ awk '{ list[$0]++ }> END { for (i in list) print i }' /usr/share/dict/words > /tmp/wlistДалее, напишите две программы. Каждая должна читать новый список и сохранять каждое прочитанное слово в дереве и массиве соответственно. Вторая программа должна использовать для сортировки массива
qsort()bsearch()gravyИспользуйте вывод
ps11. Повторно запустите обе программы, использовав оригинальный отсортированный словарный файл, и посмотрите, как изменятся временные результаты (если они вообще изменятся).
ТЕЛЕГРАМКанал с обзорами, анонсами новинок и книжными подборками
Книжный Вестник
Бот для удобного поиска книг (если не нашлось на сайте)
Поиск книг
Свежие любовные романы в удобных форматах
Любовные романы
О психологии, саморазвитии и личностном росте
Саморазвитие
Детективы и триллеры, все новинки
Детективы
Фантастика и фэнтези, все новинки
Фантастика
Отборные классические книги
Классика
ВКОНТАКТЕБиблиотека с любовными романами, которая наверняка придётся по вкусу женской части аудитории
Любовные романы
Библиотека с фантастикой и фэнтези, а также смежных жанров
Фантастика
Самые популярные книги в формате фб2
Топ фб2
книги