Книга: UNIX — универсальная среда программирования

7.5 Сигналы и прерывания

7.5 Сигналы и прерывания

Теперь мы рассмотрим работу с сигналами извне (такими, как прерывания) и ошибками программы. Последние возникают главным образом из-за некорректных обращений к памяти, выполнения привилегированных команд или при выполнении операций с плавающей запятой. Наиболее распространенными внешними сигналами являются прерывание, посылаемый при печати символа del, выйти, генерируемый символом FS (ctrl-), отбой, вызываемый завершением телефонной связи, и закончить, генерируемый командой kill. Когда происходит одно из этих событий, посылается сигнал всем процессам, запущенным с того же терминала, и если не были приняты другие меры, процесс завершается. Для большинства сигналов пишется файл образа памяти, который может потребоваться при поиске ошибок (см. справочное руководство по adb(1), sdb(1)).

Системный вызов signal изменяет действие, заданное по умолчанию. Он имеет два аргумента: номер, определяющий сигнал, и адрес функции или код, предписывающий игнорировать сигнал либо запустить процедуру, принятую по умолчанию. Файл <signal.h> содержит определения для различных аргументов. Так,

#include <signal.h>
signal(SIGINT, SIG_IGN);

Специфицирует игнорирование прерываний, тогда как

signal(SIGINT, SIG_DEL);

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

#include <signal.h>
char *tempfile = "temp.xxxxxx";
main() {
 extern onintr();
 if (signal(SIGINT, SIG_IGN) != SIG_IGN)
  signal(SIGINT, onintr);
 mktemp(tempfile);
 /* Process ... */
 exit(0);
}
onintr() { /* почистить, если прервано */
 unlink(tempfile);
 exit(1);
}

Почему в main имеют место проверки и двойной вызов signal? Вспомните, что сигналы посылаются всем процессам, запущенным с данного терминала. Соответственно если программа должна быть запущена не в диалоговом режиме (с помощью &), shell делает так, что она будет игнорировать прерывания. Поэтому сигналы прерывания, посланные основным процессам, не остановят ее. Если бы эта программа началась с объявления о том, что все прерывания, которые должны быть посланы подпрограмме onintr, не принимаются во внимание, были бы сведены на нет все усилия shell защитить ее при запуске в фоновом режиме.

Решение, показанное выше, состоит в том, чтобы проверить состояние обработки прерываний, если они игнорировались ранее. Функции программы в том виде, в каком она написана, зависят от возвращаемого signal предыдущего состояния конкретного сигнала. Если сигналы уже игнорировались, процесс должен продолжить это дело; в противном случае их следует перехватывать.

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

#include <signal.h>
#include <setjmp.h>
jmp_buf sjbuf;
main() {
 int onintr();
 if(signal(SIGINT, SIG_IGN) != SIG_IGN)
  signal(SIGINT, onintr);
 setjmp(sjbuf);
 /* сохранить текущую позицию стека */
 for(;;) {
  /* главный рабочий цикл */
 }
 ...
}
onintr() { /* установить если прервано */
 signal(SIGINT, onintr); /* установить
                            для следующего прерывания */
 printf("nInterruptn");
 longjmp(sjbuf, 0); /* вернуться
                       в сохраненное состояние */
}

Файл <setjmp.h> описывает тип jmp_buf как объект, в котором сохраняется позиция стека; sjbuf считается таким объектом. Функция setjmp(3) сохраняет запись о том, где выполняется программа. Значения переменных не сохраняются. Когда происходит прерывание, выполняется обращение к подпрограмме onintr, которая может печатать сообщения, устанавливать флаги и т.д. Функция longjmp берет в качестве аргумента объект, сохраненный setjmp, и возвращает управление в ячейку после вызова setjmp. Поэтому управление (и значение уровня стека) будет возвращено обратно в основную программу — ко входу в головной цикл.

Отметим, что после прерывания сигнал вновь настраивается на onintr. Это обусловлено тем, что когда сигналы возникают, они автоматически настраиваются на реакцию по умолчанию.

Некоторые программы, которые "хотят" обнаружить сигналы, просто не могут быть остановлены в произвольный момент, например в середине обновления сложных составных данных. Решение состоит в том, что подпрограмма обработки прерывания должна установить флаг и вернуться к месту вызова exit или longjmp. Выполнение программы продолжится точно с того места, где оно было прервано, а флаг прерывания будет проверен позднее.

С этим подходом связана одна трудность. Предположим, что, когда посылается сигнал прерывания, программа читается с терминала. Описанная подпрограмма непременно вызывается; она устанавливает свой флаг и возвращается. Если бы, как отмечалось выше, было верно то, что выполнение возобновляется точно с того места, где оно прервалось, программа продолжала бы чтение с терминала до ввода пользователем другой строки. Однако здесь возникает недоразумение, поскольку пользователь может не знать, что программа читает, и предположительно предпочел бы, чтобы сигнал сразу оказал действие. Для разрешения проблемы система должна закончить read, но с сообщением об ошибке, указывающим, что произошло: errno присваивается EINTR, определенное в заголовке <errno.h>, чтобы обозначить прерванный системный вызов.

Так, программы, которые "ловят" сигналы и продолжают после этого свою работу, должны быть готовы к появлению ошибок, вызванных прерванными системными вызовами. (Следует остерегаться системных вызовов read — чтение с терминала, wait, pause). Такая программа при чтении стандартного входного потока могла бы использовать фрагмент, подобный следующему:

#include <errno.h>
extern int errno;
...
if (read(0, &c, 1) <= 0) /* EOF или прерывание */
 if (errno == EINTR) { /* EOF, вызванный прерыванием */
  errno = 0; /* устанавливается для следующего раза */
 } else { /* настоящий конец файла */
  ...
 }

Очень сложно постоянно следить за тем, как реакция на сигнал комбинируется с выполнением других программ. Предположим, программа ловит сигналы прерывания и располагает средствами (типа "!"в ed) для выполнения других программ. Тогда программа могла бы выглядеть так:

if (fork() == 0)
 execlp(...);
signal(SIGINT, SIG_IGN); /* родитель игнорирует прерывание */
wait(&status); /* пока потомок не завершился */
signal(SIGINT, onintr); /* восстанавливает прерывания */

Почему? Сигналы посылаются всем вашим процессам. Предположим, программа, которую вы вызвали, ловит свои собственные сигналы прерывания, как это делает редактор. Если вы прервете выполнение подпрограммы, она получит сигнал, вернется к своему главному циклу и, возможно, начнет читать с вашего терминала. Но вызывающая программа также перейдет от wait к подпрограмме и будет читать с терминала. Два процесса, читающие с вашего терминала, создадут трудную ситуацию, так как в результате системе придется гадать, к кому попадет та или иная строка входного потока. Решение состоит в том, чтобы родительская программа игнорировала прерывания, пока не завершился процесс-потомок. Это решение нашло свое отражение при обработке сигнала в system:

#include <signal.h>
system(s) /* run command line s */
 char *s;
{
 int status, pid, w, tty;
 int (*istat)(), (*qstat)();
 ...
 if ((pid = fork()) == 0) {
  ...
  execlp("sh", "sh", "-c", s, (char*)0);
  exit(127);
 }
 ...
 istat = signal(SIGINT, SIG_IGN);
 qstat = signal(SIGQUIT, SIG_IGN);
 while ((w = wait(&status)) != pid && w != -1);
 if (w == -1)
  status = -1;
 signal(SIGINT, istat);
 signal(SIGQUIT, qstat);
 return status;
}

Несколько слов по поводу описаний: функция signal, очевидно, имеет довольно странный второй аргумент. Фактически он представляет собой указатель на функцию, поставляющую целое значение, и в то же время это тип самой подпрограммы сигнала. Две величины, SIG_IGN и SIG_DFL, имеют правильный тип, но выбраны так, что не совпадают ни с одной из существующих функции. Для любознательных покажем, как они определены для PDP-11 и VAX: определения, видимо, достаточно "неуклюжи", чтобы стимулировать использование <signal.h>.

#define SIG_DFL (int(*)())0
#define SIG_IGM (int(*)())1

Системный вызов alarm(n) обеспечивает посылку сигнала SIGALRM вашему процессу через n секунд. Сигнал будильника может быть использован для того, чтобы удостовериться в возникновении каких-то событий за соответствующее время. Если что-нибудь произошло, сигнал будильника может быть выключен; в противном случае процесс может получить управление, перехватив этот сигнал.

Для иллюстрации приведем программу timeout, которая запускает другую команду; если команда не закончила свое выполнение за определенное время, она будет завершена по звонку будильника. Например, вспомните команду watchfor из гл. 5. Вместо того чтобы запускать ее без ограничения времени работы, установите ограничение в часах:

$ timeout -3600 watchfor dmg &

Программа timeout демонстрирует почти все возможности, которые мы обсуждали в последних двух разделах. Создан процесс-потомок, родительский процесс устанавливает будильник и затем ждет, пока потомок завершит работу. Если будильник "зазвенел" первым, потомок уничтожается. Делается попытка вернуть состояние потомка при выходе.

/* timeout: set time limit on a process */
#include <stdio.h>
#include <signal.h>
int pid; /* child process id */
char *progname;
main(argc, argv)
 int argc;
 char *argv[];
{
 int sec = 10, status, onalarm();
 progname = argv[0];
 if (argc > 1 && argv[1][0] == '-') {
  sec = atoi(&argv[1][1]);
  argc--;
  argv++;
 }
 if (argc < 2)
  error("Usage: %s [-10] command", progname);
 if ((pid=fork()) == 0) {
  execvp(argv[1], &argv[1]);
  error("couldn't start %s", argv[1]);
 }
 signal(SIGALRM, onalarm);
 alarm(sec);
 if (wait(&status) == -1 || (status & 0177) != 0)
  error("%s killed", argv[1]);
 exit((status >> 8) & 0377);
}
onalarm() /* kill child when alarm arrives */
{
 kill(pid, SIGKILL);
}

Оглавление книги