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

Цилюрик Олег Иванович
Шрифт:
Примечание

В 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], чтобы дать программе возможность выполнить все требуемые операции по завершению (сбросить буферы данных на диск, закрыть файлы, сокеты и другие используемые объекты):