Linux программирование в примерах

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

10.8.1.1. Труднее, но с большим контролем: alarm и SIGALARM

Основным строительным блоком является системный вызов alarm:

 #include <unistd.h> /* POSIX */

 unsigned int alarm(unsigned int seconds);

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

Возвращаемое значение либо 0, либо, если был установлен предыдущий сигнальный интервал, число секунд, остающихся до его завершения. Однако, для процесса имеется лишь один такой сигнальный интервал; предыдущий отменяется, а новый помещается на его место.

Преимуществом здесь является то, что со своим установленным обработчиком вы можете делать при поступлении сигнала все, что хотите. Недостаток же в том, что приходится быть готовым к работе в нескольких контекстах: основном контексте и контексте обработчика сигнала.

10.8.1.2. Простой и легкий: sleep

Более легкий способ ожидания истечения фиксированного промежутка времени заключается в использовании функции sleep:

 #include <unistd.h> /* 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, и их результаты будут собраны при их завершении.

112

Исторически системы BSD использовали имя SIGCHLD, которое используется и POSIX. В System V есть сходный сигнал с именем SIGCLD. GNU/Linux определяет последний через #define как первый — см. табл. 10.1 — Примеч. автора.