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

Теперь мы рассмотрим работу с сигналами извне (такими, как прерывания) и ошибками программы. Последние возникают главным образом из-за некорректных обращений к памяти, выполнения привилегированных команд или при выполнении операций с плавающей запятой. Наиболее распространенными внешними сигналами являются прерывание, посылаемый при печати символа 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("\nInterrupt\n");

 longjmp(sjbuf, 0); /* вернуться

                       в сохраненное состояние */

}