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 <signal.h> /* 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
возвратилась бы нормально.