Олег Цилюрик - QNX/UNIX: Анатомия параллелизма
• 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:
#include <stdlib.h>
#include <stream.h>
#include <errno.h>
#include <signal.h>
int main(int argc, char *argv[]) {
cout << "SIGNO";
for (int i = _SIGMIN; i <= _SIGMAX; i++) {
if (i % 8 == 1) cout << endl << i << ':';
int res = sigaction(i, NULL, NULL);
cout << 't' << ((res != 0 && errno == EINVAL) ? '-' : '+');
}
cout << endl;
return EXIT_SUCCESS;
}
И результат его выполнения:
SIGNO
1: + + + + + + + +
9: + + + + + + + +
17: + + + + + + + +
25: + + + + + + + +
33: + + + + + + + +
41: + + + + + + + +
49: + + + + + + + +
57: - - - - - - - -
Система «считает» все сигналы 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 запущенного процесса:
# pidin
...
220//86 1 /s2 10 r STOPPED
...
И посылаем процессу сигнал завершения:
# kill -9 2207786 или kill -SIGKILL 2207786
Таким же образом, как показано командой kill, мы будем посылать сигналы процессам «извне» и в описываемых далее тестах, не останавливаясь подробно, как это происходит, в том числе и для сигналов реального времени (41…56).
Предыдущий пример можно переписать (файл s4.cc) для обеспечения часто требуемой на практике защиты от немедленного прерывания выполнения по [Ctrl+C], чтобы дать программе возможность выполнить все требуемые операции по завершению (сбросить буферы данных на диск, закрыть файлы, сокеты и другие используемые объекты):
#include <stdlib.h>
#include <iostream.h>
#include <signal.h>
#include <unistd.h>
static void handler(int signo) {
cout << "Saving data ... wait.r" << flush;
sleep(2); // здесь выполняются все завершающие действия!
cout << " " << flush;
exit(EXIT_SUCCESS);
}
int main() {
signal(SIGINT, handler);
signal(SIGSEGV, SIG_DFL);
signal(SIGTERM, SIG_IGN);
while (true) pause();
}
Оператор ожидания pause() при поступлении сигналов завершается с возвратом -1, а переменная errno устанавливается в EINTR. Этот оператор дает нам еще один способ (файл s3.cc) неявного (без явной установки обработчиков) использования сигналов:
#include <stream.h>
#include <stdlib.h>
#include <unistd.h>
int main(void) {
alarm(5);
cout << "Waiting to die in 5 seconds ..." << endl;
pause();
return EXIT_SUCCESS;
}
Описываемая модель обработки сигналов обладает рядом недостатков, считается устаревшей и, более того, как было показано, не обеспечивает надежную обработку сигналов. Тем не менее эту модель достаточно широко применяют в простых случаях, например при необходимости установить тайм-аут для некоторой операции. Вот как, к примеру, устанавливается тайм-аут ожидания установления соединения в TCP/IP-клиенте [9]:
void alarm_handler(int sig) { return; }
int main() {
...
signal(SIGALRM, alarm_handler); alarm(5);
int rc = connect( ... );
alarm(0);
if (rc < 0 && errno == EINTR)
cout << "Истек тайм-аут" << endl, exit(EXIT_FAILURE);
...
}
Здесь уместно напомнить немаловажное обстоятельство, связанное с сигналами, которое обделяется вниманием во многих руководствах по программированию: большинство блокирующих вызовов API (connect(), delay(), wait(), waitid() и многие другие) будут разблокированы при получении блокированным потоком любого сигнала. Такие вызовы API, как pause() и sigwait(), вообще предназначены только для выполнения пассивной блокировки до момента поступления сигнала. Многие их них возвращают значение или устанавливают в качестве кода системной ошибки errno значение EINTR, специально отведенное для отражения такого результата завершения, как прерывание поступившим извне сигналом. Мы неоднократно будем использовать это обстоятельство в тексте примеров программного кода, например:
