Обозначения: 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.
Чтобы увидеть список поддерживаемых сигналов, вы можете использовать '
являются сигналами реального времени, сложная тема, которую мы не будем рассматривать.
10.3.2. Программная отправка сигналов:
raise
Помимо внешнего генерирования, сигнал может быть отправлен непосредственно самой программой с использованием стандартной функции С
raise
:
#include <signal.h> /* 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, по крайней мере, однажды. */