— сигнал трассировочного прерывания (trace trap). Это особый сигнал, который в сочетании с системным вызовом
ptrace
используется отладчиками: sdb, adb, gdb. По умолчанию сигнал приводит к аварийному завершению. Обработка сигнала не сбрасывается, когда он перехватывается.
•
SIGTSTP [24]
— терминальный сигнал остановки (terminal stop signal). Генерируется при нажатии специальной комбинации остановки [Ctrl+Z]. Аналогичен сигналу
SIGSTOP
, но, в отличие от последнего, может быть перехвачен или проигнорирован.
•
SIGTTIN [26]
— остановка фонового процесса, если он пытается прочитать данные со своего управляющего терминала (background process attempting read).
•
SIGTTOU [27]
— остановка фонового процесса, если он пытается писать данные на свой управляющий терминал (background process attempting write).
•
SIGURG [21]
—
сигнал о поступлении в буфер сокета срочных (приоритетных) данных (high bandwidth data is available at a socket, urgent condition on I/O channel) уведомляет процесс, что по открытому им сетевому соединению получены внеочередные данные.
•
SIGUSR1 [16]
,
SIGUSR2 [17]
— зарезервированные сигналы пользователя. Для этих сигналов предопределенной реакцией в QNX является завершение процесса (хотя естественнее ожидать, и так это предлагает POSIX, реакцию «игнорировать сигнал»), и реакцию на них должен определять пользователь. Так же как и сигнал
SIGTERM
, эти сигналы никогда не посылаются системой.
•
SIGVTALRM [28]
— сигнал виртуального таймера (virtual timer expired). Подобно
SIGPROF
и
SIGALRM
, этот сигнал возбуждается по истечении времени таймера (это третий из доступных таймеров), который измеряет время процессора только в пользовательском режиме (таймер устанавливается заданием первого параметра
setitimer
, равным
ITIMER_VIRTUAL
).
•
SIGXCPU [30]
— сигнал о превышении лимита процессорного времени (CPU time limit exceeded). Посылается процессу при исчерпании им ранее установленного лимита процессорного времени. Действие по умолчанию — аварийное завершение.
•
SIGXFSZ [31]
— сигнал о превышении предела, установленного на размер файла (file size limit exceeded). Действие по умолчанию — аварийное завершение.
•
SIGWINCH [20]
— сигнал, который генерируется (в консольном режиме
pterm
и
xterm
эмулируют его вручную при изменении их размеров) при изменении размера окна (window size change) для запущенного в окне приложения (mc, mqc…), чтобы оно перерисовало свой экран вывода.
Примечание
В QNX определено еще два специфических сигнала, которые вряд ли должны представлять для нас интерес:
•
SIGIOT [6]
— IOT-инструкция; никогда не генерируется для платформы x86.
•
SIGPWR [19]
— сигнал power-fail restart о котором в технической документации QNX ничего не говорится, но в преамбуле, описывающей нововведения версии 6.2.1, сказано: «corrected SIGPWR to SIGTERM», то есть этот сигнал, очевидно, — рудимент прежних версий системы.
Примечание
POSIX допускает, что не все сигналы могут быть реализованы. Более того, допускается ситуация, когда некоторое символическое имя сигнала определено, но сам сигнал отсутствует в системе (изменения такого рода вполне могут наблюдаться при переходе от одной версии QNX к другой). Для диагностики реального наличия сигнала можно воспользоваться рекомендацией, приведенной в информативной части стандарта POSIX 1003.1: наличие поддержки сигнала сообщает вызов функции
sigaction
с аргументами
act
и
oact
, установленными в
NULL
. Приведем простейший тест ( файл s1.cc), реализующий рекомендацию POSIX в QNX 6.2.1:
«считает» все сигналы 1…56 реализуемыми, а последние 8 специфических сигналов QNX, как упоминалось выше, не допускают применения к ним
sigaction
. Здесь с учетом цитировавшейся выше раскладкой сигналов QNX есть небольшая загадка: максимальным номером POSIX-сигнала, определенного в
<signal.h>
, является 31 (
SIGXFSZ
– 31); там же в комментарии есть фраза: «допустимый диапазон пользовательских сигналов — от 1 до 56, используемых ядром — от 57 до 64». Непонятно, в каком качестве используются сигналы 32–40, непосредственно предшествующие сигналам реального времени (41–56) и диагностируемые
sigaction
как действительные (valid)? Позже мы увидим, что они обслуживаются системой наравне с документированными сигналами.
Традиционная обработка сигнала
В этой части изложения мы рассмотрим традиционные модели перехвата сигналов и установки для них собственных обработчиков (в том числе и игнорирование или восстановление стандартной обработки по умолчанию). Термин «традиционный» здесь означает, что мы бегло рассмотрим обработку сигналов применительно к процессам и стандартным сигналам UNIX (не сигналам реального времени), то есть в том изложении, как она традиционно рассматривается в литературе по UNIX (и здесь сигнал воспринимается, конечно же, единственным потоком приложения, а не процессом, но в этом случае различие не принципиально). Позже мы рассмотрим модель обработки сигналов реального времени и расширим ее на многопоточные приложения.
«Старая» модель обработки сигнала
В ранних версиях UNIX была принята единственная модель обработки сигналов, основанная на функции
signal
, которая подразумевает семантику так называемых «ненадежных сигналов», принятую в этих ОС. Позже эта модель была подвержена радикальной критике, вскрывшей ее «ненадежность». Данная модель сохранена для совместимости с ранее разработанным программным обеспечением. Она обладает существенными недостатками, основными из которых являются:
• процесс не может заблокировать сигнал, то есть отложить получение сигнала на период выполнения критических участков кода;
• каждый раз при получении сигнала его диспозиция устанавливается на действие по умолчанию, и при необходимости продолжить обработку поступающих сигналов требуется повторно восстанавливать требуемый обработчик.
Вот пример ( файл s2.cc) использования этой модели в коде, который уже стал иллюстративным образцом и кочует из одного источника в другой:
Ненадежная модель реакции на сигнал
#include <iostream.h>
#include <signal.h>
#include <unistd.h>
// обработчик сигнала SIGINT
static void handler(int signo) {
// восстановить обработчик:
signal(SIGINT, handler);
cout << "Получен сигнал SYSINT" << endl;
}
int main {
// устанавливаются диспозиции сигналов:
signal(SIGINT, handler);
signal(SIGSEGV, SIG_DFL);
signal(SIGTERM, SIG_IGN);
while(true) pause;
}
Примечание
Макросы
SIG_DFL
и
SIG_IGN
определяются так:
#define SIG_ERR (( void(*)(_SIG_ARGS))-1 )
#define SIG_DFL (( void(*)(_SIG_ARGS))0)
#define SIG_IGN (( void(*)(_SIG_ARGS))1)
#define SIG_HOLD (( void(*)(_SIG_ARGS))2)
где
_SIG_ARGS
— это фактически тип
int
.
SIG_DFL
и
SIG_IGN
устанавливают диспозиции сигнала «по умолчанию» и «игнорировать» соответственно, а о
SIG_HOLD
мы будем отдельно говорить позже.
Выполнение этой программы вам будет не так просто прекратить: на комбинацию завершения [Ctrl+C] она отвечает сообщением о получении сигнала... и все. Воспользуемся для этого посылкой программе опять же сигнала, но из другого процесса (другого экземпляра командного интерпретатора). Смотрим PID запущенного процесса: