QNX/UNIX: Анатомия параллелизма

должен определять пользователь. Так же как и сигнал 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:

#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 << '	' << ((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>