Сигналы инициируются некоторыми событиями в системе и посылаются процессу для его уведомления о том, что произошло нечто неординарное, требующее определенной реакции. Порождающее сигнал событие может быть действием пользователя или может быть вызвано другим процессом или ядром операционной системы. Сигналы являются одним из самых старых и традиционных механизмов UNIX.
Уже из этого краткого описания можно заключить, что:
• действия, вызываемые для обработки сигнала, являются принципиально асинхронными;
• сигналы могут быть использованы как простейшее, но мощное средство межпроцессного взаимодействия.
Все сигналы определяются целочисленными константами, но для программиста это в принципе не так важно, поскольку каждому сигналу приписано символическое наименование вида SIG*. Все относящиеся к сигналам определения находятся в заголовочном файле
Посланный сигнал обрабатывается получившим его потоком или процессом (как уже обсуждалось ранее, собственно процесс ничего не может обрабатывать: это пассивная субстанция; понятно, что речь в таком контексте идет об обработке сигнала главным потоком процесса). Поток может отреагировать на полученный сигнал следующими способами (иногда действие, установленное для конкретного сигнала, называют диспозицией сигнала):
• Стандартное действие — выполнение действия, предписанного для обработки этого сигнала по умолчанию. Для многих сигналов действием по умолчанию является завершение, но это необязательно; есть сигналы, которые по умолчанию игнорируются. Для большей части сигналов, чьим действием по умолчанию является принудительное завершение процесса, предписано действие создания дампа памяти при завершении (core dump), но для некоторых, например SYSINT (завершение по [Ctrl+C]), определено такой дамп при завершении не создавать.
• Игнорирование сигнала — сигнал не оказывает никакого воздействия на ход выполнения потока получателя.
• Вызов обработчика — по поступлению сигнала вызывается функция реакции, определенная пользователем. Если для сигнала устанавливается функция-обработчик, то говорят, что сигнал перехватывается (относительно стандартного действия).
Для различных сигналов программа может установить различные механизмы обработки. Более того, в ходе выполнения программа может динамически переопределять реакции, установленные для того или иного сигнала.
Для большинства сигналов их воздействие можно перехватить из программного кода или игнорировать, но не для всех. Например, сигналы SIGKILL и SIGSTOP не могут быть ни перехвачены, ни проигнорированы. Другой пример — описываемые далее специальные сигналы QNX, начиная с SIGSELECT и далее.
В QNX определены 64 сигнала в трех диапазонах:
• 1…40 — 40 POSIX-сигналов общего назначения;
• 41…56 — 16 POSIX-сигналов реального времени, введенных в стандарт позже (от SIGRTMIN до SIGRTMAX);
• 57…64 — 8 сигналов, используемых в QNX Neutrino для специальных целей.
Начнем со специальных сигналов. Эти сигналы не могут быть проигнорированы или перехвачены: попытка вызвать signal() или sigaction() (или вызов ядра SignalAction() native API) завершится для них с ошибкой EINVAL. Более того, эти сигналы всегда блокированы в пользовательском приложении, и для них установлено разрешение очереди обслуживания (очереди сигналов будут подробно рассмотрены далее). Попытка разблокировать эти сигналы, используя sigprocmask() (SignalProcmask() — native API), будет проигнорирована. Эти сигнальные механизмы используются, в частности, графической системой Photon для ожидания событий GUI и функцией select() для ожидания ввода/вывода на множестве дескрипторов (один из фундаментальных механизмов UNIX). Вот определения некоторых из этих сигналов:
#define SIGSELECT (SIGRTMAX + 1)
#define SIGPHOTON (SIGRTMAX + 2)
В силу своей недоступности эта группа сигналов представляет небольшой интерес для разработчика приложений.
Далее перейдем к POSIX-сигналам общего назначения (1…40), из которых назовем только самые употребляемые (пока мы описываем все сигналы в классической UNIX-нотации, не углубляясь в нюансы, например такие, как особенности реакции на них в многопоточном окружении):
• SIGABRT (+) [6] — аварийное завершение процесса (process abort signal). Посылается процессу при вызове им функции abort(). В результате обработки сигнала SIGABRT произойдет то, что спецификация XSI описывает как аварийное завершение.
• SIGALRM [14] — наступление тайм-аута таймера сигналов (real-time alarm clock). Посылается при срабатывании ранее установленного пользовательского таймера (таймер устанавливается заданием первого параметра setitimer(), равным ITIMER_REAL), например при помощи системного вызова alarm().
• SIGBUS (+) [10] — сигнал ошибки на шине (bus error). Этот сигнал посылается при возникновении некоторых аппаратных ошибок (зависит от платформы); обычно он генерируется при попытке обращения к допустимому виртуальному адресу, для которого нет физической страницы.
• SIGCHLD [18] — сигнал завершения или остановка дочернего процесса (child process terminated or stopped). По умолчанию родительский процесс игнорирует этот сигнал, поэтому если нужно получать уведомление о завершении порожденного процесса, этот сигнал нужно перехватывать. Для этого сигнала определен синоним:
#define SIGCLD SIGCHLD
• SIGCONT [25] — продолжение работы остановленного процесса (continue executing if stopped). Это сигнал управления выполнением процесса, который возобновляет его выполнение, если ранее он был остановлен сигналом SIGSTOP; если процесс не остановлен, он игнорирует этот сигнал.
• SIGDEADLK [7] — сигнал, говорящий о возникновении «мертвой» блокировки потока на мьютексе (mutex deadlock occurred). Эта ситуация будет подробно рассмотрена далее, когда речь пойдет о примитивах синхронизации (глава 4).
• SIGEMT [7] — ЕМТ-инструкция (emulator trap). Как видно из сравнения с предыдущим сигналом, у них один код, то есть в QNX SIGDEADLK и SIGEMT — это один сигнал.
• SIGFPE (+) [8] — недопустимая арифметическая операция с плавающей точкой (floating point exception).
• SIGHUP [1] — сигнал освобождения линии, разрыв связи с управляющим терминалом (hangup signal). Посылается всем процессам, подключенным к управляющему терминалу при отключении терминала (обычно управляющий терминал группы процесса является терминалом пользователя, но это не всегда так). Этот сигнал также посылается всем членам сеанса, если завершает работу лидер сеанса (обычно процесс командного интерпретатора), связанного с управляющим терминалом (это гарантирует, что, если не были приняты специальные меры, при выходе пользователя из системы будут завершены все запущенные им фоновые процессы).
• SIGILL [4] — попытка выполнения недопустимой инструкции процессора (illegal instruction); обработка сигнала не сбрасывается, когда он перехватывается.
• SIGINT (-) [2] — принудительное прерывание процесса (interrupt); это тот сигнал, который генерируется при нажатии [Ctrl+C]. Это обычный способ завершения выполняющегося процесса.
• SIGKILL (+) [9] — уничтожение процесса (kill); этот сигнал может активизироваться командой kill -9
• SIGPIPE [13] — попытка выполнить недопустимую запись в канал или сокет, для которых принимающий процесс уже завершил работу (write on pipe or socket when recipient is terminated, write on pipe with no reader).
• SIGPOLL [22] — сигнал уведомления об одном из опрашиваемых событий (pollable event). Этот сигнал генерируется системой, когда некоторый открытый дескриптор файла готов для ввода или вывода. Этот сигнал имеет синоним (наименование SIGPOLL более известно из UNIX System V):
#define SIGIO SIGPOLL
• SIGPROF [29] — сигнал профилирующего таймера (profiling timer expired). Как и сигнал SIGALRM, этот сигнал возбуждается по истечении времени таймера (но это другой таймер), который используется для измерения времени выполнения процесса в пользовательском и системном режимах (таймер устанавливается заданием первого параметра setitimer(), равным ITIMER_PROF).
• SIGQUIT (-) [3] — выход из процесса (quit).
• SIGSEGV (+) [11] — обращение к некорректному адресу памяти, ошибка защиты памяти, нарушение границ сегмента памяти (invalid memory reference, segmentation violation).
• SIGSTOP [23] — временная остановка процесса (sendable stop signal not from tty). Если пользователь вводит с терминала [Ctrl+Z], то активному процессу посылается этот сигнал и процесс приостанавливается. Позже процесс может быть возобновлен с точки остановки при получении сигнала SIGCONT. Этот сигнал нельзя проигнорировать или перехватить.
• SIGSYS (+) [12] — некорректный системный вызов (invalid system call, bad argument to system call).
• SIGTERM [15] — программный сигнал завершения (software termination signal from kill). Программист может использовать этот сигнал для того, чтобы дать процессу время для «наведения порядка», прежде чем посылать ему сигнал SIGKILL. Именно этот сигнал посылается по умолчанию командой kill без параметра, указывающего сигнал.
• SIGTRAP [5] — сигнал трассировочного прерывания (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:
#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
#include
#include
// обработчик сигнала 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
#include
#include
#include
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
#include
#include
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, специально отведенное для отражения такого результата завершения, как прерывание поступившим извне сигналом. Мы неоднократно будем использовать это обстоятельство в тексте примеров программного кода, например:
if (delay(100) != 0)
В данном случае учитываем, что функция delay() возвращает нереализованный остаток «заказанного» ей ожидания, который может быть ненулевым только при прерывании этого ожидания сигналом извне (нулевое значение соответствует «естественному» истечению времени задержки).
Модель надежных сигналов
В более поздней («новой») модели обработки сигналов (называемой еще моделью надежных сигналов) используются не единичные сигналы, а наборы сигналов — тип sigset_t.
Примечание
POSIX требует, чтобы в реализации тип sigset_t определялся таким образом, чтобы он мог «вместить» все определенные в системе сигналы; для QNX это число равно 64. Определение типа sigset_t в QNX, как и большинство фундаментальных для системы определений, находится в заголовочном файле <target_nto.h> :
struct { long bits[2]; }
Понятно, что в этом случае тип sigset_t — это битовая маска, но на практике знание представления этого типа не имеет никакой ценности для программиста, так как все операции над ним выполняются набором специальных операций, так что совершенно обоснованно этот тип можно считать абстрактным.
Для формирования сигнальных наборов определяется набор специальных операций:
• sigemptyset(sigset_t *set) — инициализирует набор set, исключая из него все сигналы;
• sigfillset(sigset_t *set) — инициализирует набор set, включая в него все сигналы;
• sigaddset(sigset_t *set, int signo) — добавляет в инициализированный набор set единичный сигнал signo;
• sigdelset(sigset_t *set, int signo) — удаляет из инициализированного набора set единичный сигнал signo.
В качестве signo в функциях добавления и удаления единичных сигналов используется символическая константа, соответствующая сигналу (такая как SIGINT), либо численное значение сигнала, но в этом случае код становится зависимым от системы. Легко увидеть, что, пользуясь совокупностью этих 4-х операций, можно сформировать любой произвольный набор сигналов. Например:
sigset_t sig;
sigemptyset(&sig);
sigaddset(&sig, SIGPOLL);
sigaddset(&sig, SIGALRM);
Этот фрагмент кода формирует сигнальный набор, состоящий из двух сигналов: SIGPOLL и SIGALRM.
Диспозиция обработки каждого сигнала в этой модели устанавливается функцией:
int sigaction(int signo, const struct sigaction *act, struct sigaction *oact);
где signo — номер (имя) сигнала, для которого устанавливается диспозиция;
act — определение нового обработчика сигнала;
oact — структура (если указано не NULL), где будет сохранено описание ранее установленного обработчика (например, для последующего восстановления реакции).
Структура описания обработчика sigaction определена так (мы исключили из определения часть структуры, предназначенную для компилятора Watcom, QNX 4.X):
struct sigaction {
#define sa_handler un._sa_handler
#define sa_sigaction un._sa_sigaction
union {
void (*_sa_handler)(_SIG_ARGS);
void (*_sa_sigaction)(int, siginfo_t*, void*);
} un;
int sa_flags;
sigset_t sa_mask;
};
Примечание
Это определение по форме, но не по содержанию отличается от описания, показанного в POSIX и используемого во многих традиционных UNIX [5] (обратите внимание на изменение порядка следования полей маски и флагов; это может стать преградой для прямой инициализации структуры в стиле C++ из соображений переносимости):
struct sigaction {
/* указатель на функцию обработчика сигнала */
void (*sa_handler)(int);
/* сигналы, блокирующиеся во время обработки */
sigset_t sa_mask;
/* флаги, влияющие на поведение сигнала */
int sa_flags;
/* указатель на функцию обработчика сигнала */
void (*sa_sigaction)(int, siginfo_t*, void*);
};
Определения #define в первых строках описания — это обычная в QNX практика переопределения имен для компиляторов, «не понимающих» анонимных (неименованных) объединений ( union ). Легко видеть, что даже размеры структур в этих двух определениях (QNX и POSIX) будут отличаться, что подсказывает необходимость соблюдения здесь особой тщательности при использовании.
Первое поле sa_handler определяет обработчик, устанавливаемый для сигнала в традиционной модели. Это может быть:
• SIG_DFL — восстановить обработчик сигнала, принятый по умолчанию (определения SIG_DFL и SIG_IGN см. в предыдущем разделе);
• SIG_IGN — игнорировать данный сигнал;
• адрес функции-обработчика, устанавливаемой как реакция на поступление этого сигнала. Эта функция будет выполняться при поступлении сигнала signo, и в качестве аргумента вызова она получит значение signo (одна функция может выступать как обработчик целой группы сигналов). Управление будет передано этой функции, как только процесс получит сигнал, какой бы участок кода при этом ни выполнялся. После возврата из функции управление будет возвращено в ту точку, в которой выполнение процесса было прорвано.
Второе поле sa_mask демонстрирует первое применение набора сигналов: сигналы, установленные в sa_mask, будут блокироваться на время выполнения обработчика sa_handler (при вызове sa_handler и сам сигнал signo будет неявно добавлен в набор sa_mask, поэтому его можно не указывать явно). Это не значит, что поступившие в это время сигналы будут игнорироваться и теряться, просто их обработка будет отложена до завершения работы обработчика sa_handler.
Поле sa_flags может использоваться для изменения характера реакции на сигнал signo. Возможны следующие значения поля флагов:
• SA_RESETHAND — после выполнения функции обработчика будет восстановлен обработчик по умолчанию (SIG_DFL, что соответствует духу модели «ненадежных сигналов» и позволяет воспроизводить ее поведение);
• SA_NOCLDSTOP — используется только для сигнала SIGCHLD; флаг указывает системе не генерировать для родительского процесса SIGCHLD от порожденных процессов, которые завершаются посредством SIGSTOP.
• SA_SIGINFO — при этом будет использована обработка сигналов на базе очереди сигналов (модель сигналов реального времени). По умолчанию используется простая обработка: результат воздействия нескольких сигналов определяется последним поступившим. В случае установки этого флага будет использована расширенная форма обработчика sa_sigaction (при этом поле sa_handler не будет использоваться). Обработчику будет передаваться дополнительная информация о сигнале — структура siginfo_t (его номер, PID пославшего сигнал процесса, действующий идентификатор пользователя этого процесса). Эта весьма объемная структура будет очень кратко рассмотрена ниже. Ее описание вынесено в отдельный заголовочный файл
Приведем несколько небольших и самых простых примеров использования модели надежных сигналов.
Модель надежных сигналов
1. Перехватчик сигнала SIGINT (реакция на пользовательский ввод [Ctrl+C]) (файл s8.cc):
void catchint(int signo) {
cout << "SIGINT: signo = " << signo << endl;
}
int main() {
static struct sigaction act = { &catchint, 0, (sigset_t)0 };
// запрещаем любые сигналы на время обработки SIGINT:
sigfillset(&(act.sa_mask));
// до этого вызова реакцией на Ctrl+C будет завершение задачи:
sigaction(SIGINT, &act, NULL);
for (int i = 0; i < 20; i++)
sleep(1), cout << "Cycle # " << i << endl;
}
Результатом нормального (без вмешательства оператора) выполнения приложения будет последовательность из 20 циклов секундных ожиданий, но если в процессе этих ожиданий пользователь пытается прервать работу процесса по [Ctrl+C], то он получит вывод, подобный следующему:
...
Cycle # 10
... здесь пользователь пытается прервать программу
SIGINT: signo = 2
Cycle # 11
...
2. Запрет прерывания выполнения программы с терминала. Для этого достаточно заменить строку инициализации структуры sigaction на:
static struct sigaction act = { SIG_IGN, 0, (sigset_t)0 };
Можно проигнорировать сразу несколько сигналов (прерывающих выполнение программы с клавиатуры):
sigaction(SIGINT, &act, NULL );
sigaction(SIGQUIT, &act, NULL);
Далее остановимся еще на одном вызове API-сигналов, который широко используется в этой и последующих моделях обработки (сигналы реального времени, реакция в потоках):
int sigprocmask(int how, const sigset_t *set, sigset_t *oset);
Этот вызов позволяет прочитать текущее значение (если set установлено в NULL, то параметр how игнорируется) или переустановить сигнальную маску для текущего потока. Параметры вызова:
• set — это то значение, в соответствии с которым корректируется сигнальная маска процесса;
• how — указывает, какое именно действие переустановки сигнальной маски требуется осуществить:
• SIG_BLOCK — добавить сигналы, указанные в set к маске процесса (заблокировать реакцию на эти сигналы);
• SIG_UNBLOCK — сбросить указанные set сигналы в сигнальной маске;
• SIG_SETMASK — переустановить сигнальную маску процесса на значение, указанное в set.
• oset — значение, в котором будет сохранено значение маски, предшествующее вызову (старое значение).
Как и большинство сигнальных функций, данная функция возвращает нулевое значение в результате успешного выполнения и -1 в случае неудачи, при этом код ошибки устанавливается в errno.
Именно эта функция снимает одно из самых существенных ограничений, свойственных модели «ненадежных сигналов», — позволяет заблокировать реакцию на сигналы при выполнении критических участков кода и восстановить ее при завершении выполнения этих участков.
Модель сигналов реального времени
Сигналы реального времени были добавлены в POSIX относительно недавно (1996 г.). Эта новая модель в различных ОС UNIX реализуется с разной степенью полноты и с отклонениями от спецификаций, и QNX не исключение. Модель еще до конца не отработана, поэтому возможны сюрпризы (и сейчас они будут).
Модель сигналов реального времени, которую специфицирует POSIX, устанавливается флагом SA_SIGINFO (который уже упоминался выше) при вызове sigaction(). В нижеследующем перечислении того, что предусматривает эта модель, мы излагаем в первую очередь качественную картину происходящего, предлагаемую POSIX, кое-где уточняя ее конкретными данными реализации QNX (артефакты в поведении QNX будут отдельно отмечены позже):
1. Сигналы, называемые сигналами реального времени, могут принимать значения между SIGRTMIN и SIGRTMAX. Количество таких сигналов определяется в системе константой RTSIG_MAX, которая должна быть не менее 8 (POSIX). В QNX: SIGRTMIN = 41, SIGRTMAX = 56.
2. Обработка сигналов реального времени строится на основе очереди. Если сигнал порожден N раз, то он должен быть и N раз получен адресатом (в описываемых ранее моделях это не так, в них процесс получает только единичный экземпляр сигнала). Повторные экземпляры одного и того же сигнала в модели реального времени доставляются обработчику в порядке FIFO.
3. Помимо 8-битного кода с сигналом реального времени ассоциируется 32-битное значение (si_value, мы им займемся позже), заполняемое отправителем и доставляемое получателю (что позволяет «различать» экземпляры сигналов в очереди, о которой говорилось выше).
4. Для работы с сигналами реального времени добавлено несколько новых функций. В частности, в этой модели для отправки сигнала некоторому процессу используется sigqueue() вместо kill().
Эти два вызова определяются очень близкими формами:
int kill(pid_t pid, int signo);
int sigqueue(pid_t pid, int signo, const union sigval value);
Примечание
Как мы вскоре увидим, эти две синтаксические формы одного и того же вызова отличаются лишь тем, помещают ли они в сигнал указанное значение или оставляют его нулевым. Если процесс устанавливает обработку сигнала на основании очереди, он будет получать почти одинаковым образом сигналы, посланные обоими вызовами. Разница «почти» состоит в том, что получатель на основании анализа поля si_code в siginfo_t в состоянии отличить, каким вызовом ему был послан сигнал.
Примечание
При ошибке выполнения sigqueue() (код возврата -1) могут устанавливаться (в errno) следующие коды ошибок:
• EAGAIN — недостаточно ресурсов для помещения сигнала в очередь;
• EINVAL — недопустимое значение signo или неподдерживаемый сигнал;
• ENOSYS — вызов sigqueue() не поддерживается реализацией (возможно, версией);
• EPERM — у процесса недостаточно привилегий для посылки сигнала принимающему процессу;
• ESRCH — несуществующий PID процесса получателя.
Последний случай особо интересен, так как при указании в качестве номера сигнала signo = 0 реальная посылка сигнала не производится, но устанавливается код ошибки. Это простейший и эффективный способ выяснить, выполняется ли в системе процесс с заданным PID.
5. Когда в очередь помещаются различные не заблокированные процессом (потоком) сигналы в диапазоне SIGRTMIN…SIGRTMAX, то сигналы с меньшими номерами доставляются обработчику из FIFO-очереди раньше сигналов с большими номерами (то есть сигналы с меньшими номерами имеют более высокий приоритет).
6. Обработчик для сигналов реального времени устанавливается с флагом SA_SIGINFO, а функция обработчика объявляется теперь с другим прототипом:
void func(int signo, siginfo_t* info, void* context);
Обработчик имеет больше параметров и получает больше информации. POSIX требует, чтобы тип siginfo_t содержал как минимум:
typedef struct {
int si_signo;
int si_code;
union sigval si_value; /* целое или указатель от отправителя */
} siginfo_t;
В QNX sigval определяется так (подобное определение дают и другие ОС UNIX):
union sigval {
int sival_int;
void *sival_ptr;
};
Это 32-битное значение предназначено для посылки совместно с сигналом данных для получателя, которые, как видно из синтаксиса определения sigval, могут быть целочисленным значением или указателем неспецифицированного типа.
7. Поле si_code типа siginfo_t, передаваемое получателю, определяет природу возбуждения сигнала:
• SI_ASINCIO — сигнал порожден завершением операций асинхронного ввода/вывода, запущенного одной из функций POSIX aio_*();
• SI_MESGQ — сигнал возбуждается при помещении сообщения в пустую очередь сообщений UNIX;
• SI_QUEUE — сигнал был отправлен функцией sigqueue() (в этом разделе нас интересуют только такие сигналы);
• SI_TIMER — сигнал был порожден по истечении установленного времени интервального таймера;
• SI_USER — сигнал был отправлен функцией kill().
8. Допускается, что при возбуждении сигнала еще каким-либо механизмом (сверх перечисленных, что может определяться специфическими особенностями ОС) значение si_code может отличаться от перечисленных. Однако значение поля si_value считается актуальным только в тех случаях, когда si_code имеет одно из значений: SI_ASINCIO, SI_MESGQ, SI_QUEUE, SI_TIMER.
9. Согласно POSIX сигналы, обработчики для которых также устанавливаются с флагом SA_SIGINFO, но не входящие в диапазон сигналов реального времени, например стандартные сигналы UNIX, могут обрабатываться как на основе помещения их в очередь, так и без ее использования; выбор оставляется на усмотрение разработчика ОС.
Мы перечислили основные требования POSIX к модели обработки сигналов реального времени. Дополнения, отличия и специфические структуры данных QNX будут рассмотрены немного позже.
Весьма доходчивый пример для проверки и иллюстрации обработки сигналов реального времени приведен У. Стивенсом [2]. Мы же построим приложение, реализующее его основную идею:
Приоритеты сигналов реального времени
#include
#include
#include
#include
#include
static void handler(int signo, siginfo_t* info, void* context) {
cout << "received signal " << signo << " code = " << info->si_code <<
" val = " << info->si_value.sival_int << endl;
}
int main(int argc, char *argv[]) {
cout << "signal SIGRTMIN=" << (int)SIGRTMIN
<< " - signal SIGRTMAX=" << (int)SIGRTMAX << endl;
int opt, val, beg = SIGRTMAX, num = 3,
fin = SIGRTMAX - num, seq = 3;
// обработка параметров запуска:
while ((opt = getopt(argc, argv, "b:e n")) != -1) {
switch(opt) {
case 'b': // начальный сигнал серии
if (sscanf(optarg, "%i", &val) != 1)
perror("parse command line failed"), exit(EXIT_FAILURE);
beg = val;
break;
case 'e': // конечный сигнал серии
if (sscanf(optarg, "%i", &val) != 1)
perror("parse command line failed"), exit(EXIT_FAILURE);
fin = val;
break;
case 'n': // количество сигналов в группе посылки
if (sscanf(optarg, "%i", &val) != 1)
perror("parse command line failed"), exit(EXIT_FAILURE);
seq = val;
break;
default:
exit(EXIT_FAILURE);
}
}
num = fin - beg;
fin += num > 0 ? 1 : -1;
sigset_t sigset;
sigemptyset(&sigset);
for (int i = beg; i != fin; i += (num > 0 ? 1 : -1))
sigaddset(&sigset, i);
pid_t pid;
// вот здесь ветвление на 2 процесса
if (pid - fork() == 0) {
// дочерний процесс, здесь будут приниматься посланные сигналы
sigprocmask(SIG_BLOCK, &sigset, NULL);
for (int i = beg; i != fin; i += (num > 0 ? 1 : -1)) {
struct sigaction act, oact;
sigemptyset(&act.sa_mask);
act.sa_sigaction = handler;
// вот оно - реальное время!
act.sa_flags = SA_SIGINFO;
if (sigaction(i, &act, NULL) < 0) perror("set signal handler: ");
}
cout << "CHILD: signal mask set" << endl;
sleep(3); // пауза для посылки сигналов родителем
cout << "CHILD: signal unblock" << endl;
sigprocmask(SIG_UNBLOCK, &sigset, NULL);
sleep(3); // пауза для приема всех сигналов
exit(EXIT_SUCCESS);
}
// родительский процесс: отсюда будут посылаться сигналы
sigprocmask(SIG_BLOCK, &sigset, NULL);
// пауза для установки обработчиков дочерним процессом
sleep(1);
union sigval value;
for (int i = beg, i != fin; i += (num > 0 ? 1 : -1)) {
for (int j = 0; j < seq; j++) {
value.sival_int = j;
sigqueue(pid, i, value);
cout << "signal sent: " << i << " with val = " << j << endl;
}
}
cout << "PARENT: finished!' << endl;
exit(EXIT_SUCCESS);
}
Идея этого теста крайне проста:
• Создаются два процесса, один из которых (родительский) посылает серию последовательных (по номерам) сигналов, а второй (дочерний) должен их принять и обработать.
• Начальный и конечный номера сигналов в серии могут быть переопределены ключами -b и -е соответственно.
• Посылается не одиночный сигнал, а их повторяющаяся группа; размер группы повторений может быть переопределен ключом - n.
• В качестве значения, передаваемого с каждым сигналом, устанавливается последовательный номер его посылки в группе.
Таким образом, мы можем изменять последовательность сигналов на передаче и наблюдать последовательность их доставки к принимающему процессу. Запустим полученное приложение и сразу же командой pidin посмотрим его состояние:
1077295 1 ./s5 10r NANOSLEEP
1081392 1 ./s5 10r NANOSLEEP
Это то, что мы и предполагали получить. Рассмотрим теперь результат выполнения приложения со значениями сигналов по умолчанию (сигналы 56...54, именно в порядке убывания, в каждой группе посылается 3 сигнала):
# ./s5
signal SIGRTMIN=41 - signal SIGRTMAX=56
CHILD: signal mask set
signal sent: 56 with val = 0
signal sent: 56 with val = 1
signal sent: 56 with val = 2
signal sent: 55 with val = 0
signal sent: 55 with val = 1
signal sent: 55 with val = 2
signal sent: 54 with val = 0
signal sent: 54 with val = 1
signal sent: 54 with val = 2
PARENT: finished!
# CHILD: signal unblock
received signal 56 code = -2 val = 0
received signal 56 code = -2 val = 1
received signal 56 code = -2 val = 2
received signal 55 code = -2 val = 0
received signal 55 code = -2 val = 1
received signal 55 code = -2 val = 2
received signal 54 code = -2 val = 0
received signal 54 code = -2 val = 1
received signal 54 code = -2 val = 2
Первый сюрприз, который нас ожидает, — это общее количество сигналов реального времени, выводимое программой в первой строке. Документация (HELP QNX) утверждает:
There are 24 POSIX 1003.1b realtime signals, including:
SIGRTMIN — First realtime signal.
SIGRTMAX — Last realtime signal.
Здесь есть некоторое несоответствие: тест дает значения констант SIGRTMIN = 41 и SIGRTMAX = 56, а общее количество сигналов = 16 (POSIX, как вы помните, требует минимум 8). «Потерявшиеся» сигналы (24 – 16 = 8), очевидно, и есть те сигналы из диапазона 32…40, которые выходят за пределы общих UNIX-сигналов (1…31), но не отнесены к диапазону сигналов реального времени (41…56).
Но гораздо больший сюрприз состоит в порядке доставки сигналов из очереди FIFO принимающему процессу. Документация об этом сообщает (выделено нами):
The POSIX standard includes the concept of queued realtime signals. QNX Neutrino supports optional queuing of any signal, not just realtime signals. The queuing can be specified on a signal-by-signal basis within a process. Each signal can have an associated 8-bit code and a 32-bit value.
This is very similar to message pulses described earlier. The kernel takes advantage of this similarity and uses common code for managing both signals and pulses. The signal number is mapped to a pulse priority using SIGMAX — signo. As a result, signals are delivered in priority order with lower signal numbers having higher priority . This conforms with the POSIX standard, which states that existing signals have priority over the new realtime signals.
Изменим временной порядок возбуждения сигналов - от сигналов с меньшими номерами к сигналам с большими номерами:
# ./s5 -b54 -e56 -n2
signal SIGRTMIN=41 - signal SIGRTMAX=56
CHILD: signal mask set
signal sent: 54 with val = 0
signal sent: 54 with val = 1
signal sent: 55 with val = 0
signal sent: 55 with val = 1
signal sent: 56 with val = 0
signal sent: 56 with val = 1
PARENT: finished!
# CHILD: signal unblock
received signal 56 code = -2 val = 0
received signal 56 code = -2 val = 1
received signal 55 code = -2 val = 0
received signal 55 code = -2 val = 1
received signal 54 code = -2 val = 0
received signal 54 code = -2 val = 1
Независимо от порядка отправки сигналов порядок доставки их из очереди принимающему процессу сохраняется от старших номеров сигналов, которые являются более приоритетными, к младшим. А это в точности противоположно тому, что обещает документация, и соответствует картине, которую У. Стивенс наблюдал в ОС Sun Solaris 2.6 и которую он же комментирует словами: «Похоже, что в реализации Solaris 2.6 есть ошибка».
Выполним ту же задачу, но теперь не относительно сигналов диапазона реального времени, а относительно стандартных UNIX-сигналов. Выберем для этого произвольный диапазон сигналов (
#define SIGVTALRM 28 /* virtual timer expired */
#define SIGPROF 29 /* profiling timer expired */
#define SIGXCPU 30 /* exceeded cpu limit */
#define SIGXFSZ 31 /* exceeded file size limit */
Посмотрим результат в этом случае:
# ./s5 -b28 -e31 -n2
signal SIGRTMIN=41 - signal SIGRTMAX=56
CHILD: signal mask set
signal sent: 28 with val = 0
signal sent: 28 with val = 1
signal sent: 29 with val = 0
signal sent: 29 with val = 1
signal sent: 30 with val = 0
signal sent: 30 with val = 1
signal sent: 31 with val = 0
signal sent: 31 with val = 1
PARENT finished!
# CHILD signal unblock
received signal 31 code = -2 val = 0
received signal 31 code = -2 val = 1
received signal 30 code = -2 val = 0
received signal 30 code = -2 val = 1
received signal 29 code = -2 val = 0
received signal 29 code = -2 val = 1
received signal 28 code = -2 val = 0
received signal 28 code = -2 val = 1
QNX при установке обработчика с флагом SA_SIGINFO использует модель работы реального времени не только относительно сигналов диапазона SIGRTMIN...SIGRTMAX, но и для всего множества стандартных UNIX-сигналов. Это расширение, впрочем, не противоречит приведенному выше утверждению POSIX, что такое решение факультативно (см. пункт 9 описания модели сигналов реального времени) и оставляется на усмотрение разработчика ОС.
Любопытным может оказаться и рассмотрение реакции на сигналы, которые никак не определены в QNX (в исследуемый диапазон для сравнения включены как неопределенные, так и определенные сигналы системы):
# ./s5 -b39 -e41 -n2
signal SIGRTMIN=41 - signal SIGRTMAX=56
CHILD: signal mask set
signal sent: 39 with val = 0
signal sent: 39 with val = 1
signal sent: 40 with val = 0
signal sent: 40 with val = 1
signal sent: 41 with val = 0
signal sent: 41 with val = 1
PARENT finished!
# CHILD: signal unblock
received signal 41 code = -2 val = 0
received signal 41 code = -2 val = 1
received signal 40 code = -2 val = 0
received signal 40 code = -2 val = 1
received signal 39 code = -2 val = 0
received signal 39 code = -2 val = 1
Для них реакция никак не отличается от реакции на другие сигналы, что, впрочем, неудивительно, учитывая замечание в цитировавшемся выше фрагменте документации о том, что возбуждение сигнала и посылка импульса (сообщения) микроядра в QNX — одно и то же, и обрабатываются они единым механизмом.
Посмотрим также реакцию системы на специальные сигналы QNX, номера которых выше SIGRTMAX (в исследуемый диапазон опять для сравнения включим как специальные сигналы (57…64), так и сигналы из диапазона 1…SIGRTMAX):
# ./s5 -b56 -e59 -n2
signal SIGRTMIN=41 - signal SIGRTMAX=56
set signal handler... Invalid argument
set signal handler... Invalid argument
set signal handler... Invalid argument
CHILD: signal mask set
signal sent: 56 with val = 0
signal sent: 56 with val = 1
signal sent: 57 with val = 0
signal sent: 57 with val = 1
signal sent: 58 with val = 0
signal sent: 58 with val = 1
signal sent: 59 with val = 0
signal sent: 59 with val = 1
PARENT: finished!
# CHILD: signal unblock
received signal 56 code = -2 val = 0
received signal 56 code = -2 val = 1
Из вывода видно, что на сигнал с номером 56 реакция ожидаемая, а на остальные сигналы реакции нет вовсе. Как и следует из предупреждения в документации, заблокировать или изменить реакцию на эти сигналы невозможно, и попытка установки sigaction() для них завершается ошибкой.
Таким образом, система фактически никак не выделяет сигналы диапазона реального времени (41…56), но обрабатывает аналогичным образом и стандартные сигналы UNIX (1…31), и специальные сигналы QNX (57…64), и даже сигналы, никак не специфицируемые системой вообще (32…40). Корректнее говорить не об обработке сигналов реального времени и даже не о модели сигналов реального времени, а об еще одном способе работы с любыми сигналами - обработке сигналов на базе очередей сигналов.
Примечание
Для полноты картины приведем конкретную спецификацию типа siginfo_t для QNX (выше мы рассматривали минимальную спецификацию этого типа, требуемую POSIX). Спецификация весьма объемна (вся информация до конца раздела может быть безболезненно пропущена теми, кому это неинтересно), но предоставляет программисту исчерпывающую информацию о полученном сигнале:
typedef struct {
int si_signo;
int si_code; /* if SI_NOINFO, only si_signo is valid */
int si_errno;
union {
int __pad[7];
struct {
pid_t __pid;
union {
struct {
uid_t __uid;
union sigval __value;
} kill; /* si_code <= 0 SI_FROMUSER */
struct {
_CSTD clock_t __utime;
/* CLD_EXITED status, else signo */
int _status;
_CSTD clock_t __stime;
} __chld;
/* si_signo=SlGCHLD si_code=CLD_* */
} __pdata;
} __proc;
struct {
int __fltno;
void* __fltip;
void* __addr;
} fault; /* si_signo=SIGSEGV,ILL,FPE,TRAP,BUS */
} __data;
} siginfo_t;
#define si_pid __data.__proc.__pid
#define si_value __data.__proc.__pdata.__kill.__value
#define si_uid __data.__proc.__pdata.__kill.__uid
#define si_status __data.__proc.__pdata.__chld.__status
#define si_utime __data.__proc.__pdata.__chld.__utime
#define si_stime __data.__proc.__pdata.__chld.__stime
#define si_fltno __data.__fault.__fltno
#define si_trapno si_fltno
#define si_addr __data.__fault.__addr
#define si_fltip __data.__fault.__fltip
И полный перечень определений символьных констант, используемых для установки значений поля si_code :
#define SI_USER 0
#define SI_RESERVED1 (-1)
#define SI_QUEUE (-2)
#define SI_TIMER (-3)
#define SI_ASYNCIO (-4)
#define SI_MESGQ (-5)
#define SI_NOTIFY (-6)
#define SI_IRQ (-7)
// QNX managers will never use this range.
#define SI_MINAVAIL (-128)
#define SI_MAXAVAIL (-64)
#define SI_NOINFO 127
#define SI_MAXSZ 126
Значение SI_QUEUE , равное -2, — это и есть то значение, которое мы видели в выводе тестовой задачи выше.
Соображения производительности
Ранее мы производили оценку затрат производительности процессора на переключение между контекстами для процессов и для потоков (тестовые задачи, которые мы по их структуре именовали как «симметричные»). Проделаем теперь то же самое, но синхронизацию процессов выполним посылкой и приемом сигнала (переключение контекстов будет происходить именно на операторе pause() — переходе к приему сигнала) (файл p6s.cc):
Затраты на переключение процессов посылкой сигналов
#include
#include
#include
#include
#include
#include
#include
// "пустые" обработчики сигналов
static void nhand(int signo) {}
static void qhand(int signo, siginfo_t* info, void* context) {}
int main(int argc, char *argv[]) {
unsigned long N = 1000;
bool que = false;
int opt, val;
while ((opt = getopt(argc, argv, "n:q")) != -1) {
switch(opt) {
case 'n':
if (sscanf(optarg, "%i", &val) != 1)
cout << "parse command line error" << endl, exit(EXIT_FAILURE);
if (val > 0) N = val;
break;
// ключ q определяет схему обработки сигнала
case 'q':
que = true;
break;
default:
exit(EXIT_FAILURE);
}
}
// установка сигнальных обработчиков
sigset_t sig;
sigemptyset(&sig);
sigaddset(&sig, SIGUSR1);
sigprocmask(SIG_UNBLOCK, &sig, NULL);
struct sigaction act;
act.sa_mask = sig;
act.sa_sigaction = qhand;
act.sa_handler = nhand;
act.sa_flags = que ? SA_SIGINFO : 0;
if (sigaction(SIGUSR1, &act, NULL) < 0)
cout << "set signal handler" << endl, exit(EXIT_FAILURE);
pid_t pid = fork();
if (pid == -1)
cout << "fork error" << endl, exit(EXIT_FAILURE);
// кому отправлять сигнал?
pid_t did = (pid == 0 ? getppid() : pid);
unsigned long i = 0;
uint64_t t = ClockCycles();
while (true) {
kill(did, SIGUSR1);
if (++i == N) break;
pause();
}
t = ClockCycles() - t;
cout << getpid() << " -> " << did << "\t: cycles - " << t <<
"; on signal - " << (t / N) / 2 << endl;
exit(EXIT_SUCCESS);
}
Этим приложением мы можем тестировать и традиционную схему обработки сигналов (модель надежных сигналов), и схему обработки с очередью поступления сигналов (модель сигналов реального времени), когда при старте программы указан ключ -q. Посмотрим на результаты тестовых запусков:
# nice -n-19 p6s -n1000
2904115 -> 2912308 : cycles - 5792027; on signal - 2896
2912308 -> 2904115 : cycles - 5828952; on signal — 2914
# nice -n-19 p6s -n10000
2920499 -> 2928692 : cycles - 57522753, on signal - 2876
2928692 -> 2920499 : cycles - 57530378; on signal - 2876
# nice -n-19 p6s -n100000
2936883 -> 2945076 : cycles - 573730469; on signal - 2868
2945076 -> 2936883 : cycles - 573738122; on signal - 2868
# nice -n-19 p6s -n1000000
2953267 -> 2961460 : cycles - 5747418203, on signal - 2873
2961460 -> 2953267 : cycles - 5747425310; on signal - 2873
Вспомним, что при изучении тестов простого переключения процессов (см. в главе 2) мы получали цифру порядка 600 процессорных циклов на переключение. Сейчас у нас затраты заметно больше: порядка 2850 циклов, из которых «лишние» 2250 — это не что иное, как затраты на посылку и прием сигнала, возбуждение функции обработчика и ее завершение (разделить их по компонентам мы не можем). Это и может служить ориентировочной оценкой трудоемкости обмена сигналами.
Проделаем то же самое, но уже при обработке сигналов в порядке очереди их поступления:
# nice -n-19 p6s -n1000 -q
2838579 -> 2846772 : cycles - 5772106; on signal - 2886
2846772 -> 2838579 : cycles - 5782138; on signal - 2891
# nice -n-19 p6s -n10000 -q
2854963 -> 2863156 : cycles - 57194634; on signal - 2859
2863156 -> 2854963 : cycles - 57199831; on signal - 2859
# nice -n-19 p6s -n1000000 -q
2871347 -> 2879540 : cycles - 571543013; on signal - 2857
2879540 -> 2871347 : cycles - 571550847; on signal - 2857
# nice -n-19 p6s -n1000000 -q
2887731 -> 2895924 : cycles - 5715903548; on signal - 2857
2895924 -> 2887731 : cycles - 5715908318; on signal - 2857
Это практически те же цифры, поэтому мы можем предположить, что, вообще-то говоря, для всех рассмотренных ранее схем обработки реализуется один и тот же внутренний механизм приема сигналов, который только лишь модифицируется в зависимости от используемой схемы.
Сигналы в потоках
Модель реакций на сигналы многопоточных приложений не проработана до конца в рамках POSIX и находится на стадии предварительных предложений. Тем не менее в системах с развитой многопоточностью (а QNX — именно такая система) эта сторона вопроса не может игнорироваться, и не только потому, что потоки в комбинации с сигналами могут создавать мощные конструктивные элементы программ, а еще и потому, что непроизвольные разблокирующие или завершающие операции, инициируемые сигналами, могут породить очень серьезные проблемы в случае многопоточности (мы еще будем возвращаться к этим вопросам по тексту). А раз так, то в этих случаях система должна обязательно предлагать некоторую модель функционирования (удачную или не очень).
Для того чтобы не допускать разночтений в вопросе, обратимся сначала к оригинальному фрагменту документации, описывающему принятую модель:
The original POSIX specification defined signal operation on processes only. In a multi-threaded process, the following rules are followed:
*The signal actions are maintained at the process level. If a thread ignores or catches a signal, it affects all threads within the process.
*The signal mask is maintained at the thread level. If a thread blocks a signal, it affects only that thread.
*An un-ignored signal targeted at a thread will be delivered to that thread alone.
*An un-ignored signal targeted at a process is delivered to the first thread that doesn't have the signal blocked. If all threads have the signal blocked, the signal will be queued on the process until any thread ignores or unblocks the signal. If ignored, the signal on the process will be removed. If unblocked, the signal will be moved from the process to the thread that unblocked it.
Все достаточно однозначно: обработчики сигналов определяются на уровне процесса, а вот сигнальные маски, определяющие, реагировать ли на данный сигнал, - на уровне каждого из потоков.
Для манипулирования сигнальными масками на уровне потоков нам придется использовать функцию SignalProcmask() (естественно, из состава native API, поскольку эта модель не декларирована POSIX):
#include
int SignalProcmask(pid_t pid, int tid, int how, const sigset_t* set,
sigset_t* oldset);
Видна прямая аналогия с рассматривавшейся ранее функцией sigprocmask(). Да это и неудивительно, поскольку sigprocmask() является POSIX-«оберткой» к SignalProcmask(). Только рассматриваемый вызов имеет два «лишних» начальных параметра: PID и TID потока, к маске которого применяется действие. Если pid — 0, то предполагается текущий процесс, если tid = 0, то pid игнорируется и предполагается текущий поток, вызывающий функцию.
Остальные параметры соответствуют параметрам sigprocmask() (дополнительно появляется возможное значение SIG_PENDING для how).
Рассмотрим, как это работает на примере простейшего кода (файл s6.cc):
Сигналы, обрабатываемые в потоках
#include
#include
#include
#include
#include
#include
#include
static void handler(int signo, siginfo_t* info, void* context) {
cout << "SIG = " << signo << ";
TID = " << pthread_self() << endl;
}
sigset_t sig;
void* threadfunc(void* data) {
SignalProcmask(0, 0, SIG_UNBLOCK, &sig, NULL);
while (true) pause();
}
int main() {
sigemptyset(&sig);
sigaddset(&sig, SIGRTMIN);
sigprocmask(SIG_BLOCK, &sig, NULL);
cout << "Process " << getpid() << ", waiting for signal " <<
SIGRTMIN << endl;
struct sigaction act;
act.sa_mask = sig;
act.sa_sigaction = handler;
act.sa_flags = SA_SIGINFO;
if (sigaction(SIGRTMIN, &act, NULL) < 0)
perror("set signal handler: ");
const int thrnum = 3;
for (int i = 0; i < thrnum; i++)
pthread_create(NULL, NULL, threadfunc, NULL);
pause();
exit(EXIT_SUCCESS);
}
Для анализа этого и последующих фрагментов нам будет недостаточно команды kill, поэтому сделаем простейший «передатчик» плотной (в смысле минимального интервала следования) последовательности повторяющихся сигналов (файл k6.cc). Выполнение этого тестера, например по команде:
# k6 -p214005 -s41 -n100
направляет процессу с PID = 214005 последовательность из 100 сигналов с кодом 41 (SIGRTMIN). Посылая нашему процессу-тестеру последовательность из N сигналов, мы получим N сообщений вида:
SIG = 41; TID = 4
Примечание
Здесь удобный случай показать разницу между обработкой сигналов на базе очереди и простой обработкой (модель надежных сигналов). Для этого заменим две строки заполнения структуры sigaction на:
act.sa_handler = handler;
act.sa_flags = 0;
а заголовок функции handler() перепишем так: static void handler(int signo) . Если теперь мы в точности повторим предыдущий тест, то при посылке процессу- тестеру последовательности из N сигналов мы получим всего одно сообщение все того же вида. Это наблюдение интересно еще и тем, что оно показывает, что алгоритм взаимодействия сигнала с потоками не зависит от того, какая обработка установлена для этого сигнала: на основе модели сигналов реального времени или на основе модели надежных сигналов.
Сколько бы раз мы ни повторяли тестирование, идентификатор потока, получающего и обрабатывающего сигнал, всегда будет равен 4. Что же происходит:
• главный поток (TID = 1) создает 3 новых потока (TID = 2, 3, 4);
• главный поток переходит в пассивное ожидание сигналов, но в его маске доставка посылаемого сигнала (41) заблокирована;
• выполнение функции потока начинается с разблокирования ожидаемого сигнала;
• … 3 потока (TID = 2, 3, 4) ожидают поступления сигнала;
• при поступлении серии сигналов вся их очередь доставляется и обрабатывается одним потоком с TID = 4, который тут же в цикле возвращается к ожиданию следующих сигналов.
Таким образом, сигнал доставляется одному и только одному потоку, который не блокирует этот сигнал. Обработчик сигнала вызывается в контексте (стек, области собственных данных) этого потока. После выполнения обработчика сигнал поглощается. Какому из потоков, находящихся в состоянии блокирования в ожидании сигналов (в масках которых разблокирован данный сигнал), будет доставлен экземпляр сигнала, предсказать невозможно; это так и должно быть исходя из общих принципов диспетчеризации потоков. Но реально этим потоком является поток, последним перешедший в состояние ожидания. Для того чтобы убедиться в этом, заменим предпоследнюю строку программы (pause();) на:
threadfunc(NULL);
Теперь у нас 4 равнозначных потока, ожидающих прихода сигнала, переходящих в состояние ожидания в последовательности: TID = 2, 3, 4, 1. Реакция процесса на приход сигнала изменится на:
SIG = 41, TID = 1
Изменим текст функции потока на (файл s7.cc):
void* threadfunc(void* data) {
while (true) {
SignalProcmask(0, 0, SIG_UNBLOCK, &sig, NULL);
delay(1);
SignalProcmask(0, 0, SIG_BLOCK, &sig, NULL);
delay(10);
}
}
Поведение приложения радикально изменится — происходит смена обрабатывающего потока (чтобы сократить объем вывода, серии посылаемых сигналов состоят из одного сигнала). Следует отметить, что смена обрабатывающего потока происходит между сериями, но ни в коем случае не внутри длинных серий, что можно проследить экспериментально.
SIG = 41, TID = 1
SIG = 41; TID = 4
SIG = 41; TID = 4
SIG = 41; TID = 1
SIG = 41; TID = 1
SIG = 41; TID = 4
SIG = 41; TID = 4
SIG = 41; TID = 1
SIG = 41; TID = 2
SIG = 41; TID = 2
SIG = 41; TID = 3
SIG = 41; TID = 4
Такая модель вряд ли может быть названа в полной мере «сигналами в потоках», так как сигнал в ней в конечном итоге направляется процессу как контейнеру, содержащему потоки (можно сказать и так: в оболочку адресного пространства процесса). И только после этого в контексте одного из потоков (и в случае множественных потоков, разблокированных на обработку единого сигнала, невозможно предсказать, в контексте какого из них) выполняется обработчик сигнала. Главный поток процесса (TID = 1) в этой схеме участвует в равнозначном качестве (здесь хорошо видно, что устоявшееся понятие «реакция процесса на сигнал» в строгом смысле некорректно).
Перейдем к более конкретным вопросам: как можно продуктивно использовать эту схему в многопоточных приложениях? Рассмотрим сначала случай, когда каждый из рабочих потоков разблокирован на получение одного, свойственного только ему сигнала (файл s9.cc):
Чередование потоковых сигналов
#include
#include
#include
#include
#include
#include
#include
static void handler(int signo, siginfo_t* info, void* context) {
cout << "SIG = " << signo << "; TID = " << pthread_self() << endl;
}
void* threadfunc(void* data) {
// блокировать реакцию на все сигналы
sigset_t sig;
sigfillset(&sig);
SignalProcmask(0, 0, SIG_BLOCK, &sig, NULL);
// разблокировать реакцию на свой сигнал
sigemptyset(&sig);
sigaddset(&sig, (int)data);
SignalProcmask(0, 0, SIG_UNBLOCK, &sig, NULL);
// цикл ожидания приходящих сигналов
while (true) pause();
}
int main() {
// для обработки всей группы сигналов управления потоками используем
// единую функцию реакции, иначе все было бы гораздо проще.
struct sigaction act;
sigemptyset(&act.sa_mask);
act.sa_sigaction = handler;
act.sa_flags = SA_SIGINFO;
// создаем группу однотипных потоков
const int thrnum = 3;
for (int i = SIGRTMIN; i - SIGRTMIN < thrnum; i++) {
sigset_t sig;
sigemptyset(&sig);
sigaddset(&sig, 1);
// нам нужно, чтобы главный поток не реагировал:
sigprocmask(SIG_BLOCK, &sig, NULL);
if (sigaction(i, &act, NULL) < 0) perror("set signal handler: ");
// для передачи номера сигнала используется
// трюк с подменой типа параметра:
pthread_create(NULL, NULL, threadfunc, (void*)(i));
}
// начинаем циклическую синхронизацию потоков.
for (int i = 0; ; i++) {
sleep(1);
// посылку сигнала можно (так даже будет корректнее)
// сделать так:
// union sigval val;
// val.sival_int = i;
// sigqueue(getpid(), SIGRTMIN + i % thrnum, val);
// но мы сознательно демонстрируем и приемлемость kill:
kill(getpid(), SIGRTMIN + i % thrnum);
}
}
В этой программе главный поток циклически по таймеру активизирует поочередно каждый поток. Вот фрагмент вывода работающей программы:
SIG = 41; TID = 2
SIG = 42; TID = 3
SIG = 43; TID = 4
SIG = 41; TID = 2
SIG = 42; TID = 3
SIG = 43; TID = 4
SIG = 41; TID = 2
SIG = 42; TID = 3
SIG = 43; TID = 4
Часто приходится слышать: «…хотелось бы доставить сигнал всем потокам, уведомить всех потребителей и выполнить функцию реакции в каждом потоке…», и именно в такой последовательности действий понимается модель сигналов в потоках при поверхностном с ней ознакомлении. Иногда это представляется очень интересной возможностью, и мы реализуем такую схему взаимодействия в следующем фрагменте (файл s10.cc):
Множественная реакция на сигнал
#include
#include
#include
#include
#include
#include
#include
static void handler(int signo, siginfo_t* info, void* context) {
cout << "SIG = " << signo << ", TID = " << pthread_self() << endl;
}
static void endhandler(int signo) {}
// сигнал, на который реагируют потоки:
const int SIGNUM = SIGRTMIN;
sigset_t sig;
struct threcord {
int tid;
bool noblock;
};
static vector
void* threadfunc(void* data) {
// блокирование всех прочих сигналов:
sigset_t sigall;
sigfillset(&sigall);
SignalProcmask(0, 0, SIG_BLOCK, &sigall, NULL);
// передеспетчеризация для завершения формирования вектора
sched_yield();
tharray[(int)data].noblock =
(SignalProcmask(0, 0, SIG_UNBLOCK, &sig, NULL) != -1);
while (true) {
pause();
tharray[(int)data].noblock =
!(SignalProcmask(0, 0, SIG_BLOCK, &sig, NULL) != 1);
bool nolast = false;
for (vector
i != tharray.end(); i++)
if (nolast = i->noblock) break;
// последовательная пересылка сигнала следующему потоку
if (nolast) kill(getpid(), SIGNUM);
// ... когда пересылать больше некому -
// переинициализация масок
else
for (vector
i != tharray.end(); i++)
i->noblock = (SignalProcmask(0, i->tid, SIG_UNBLOCK, &sig, NULL) != -1);
}
}
int main() {
// переопределение реакции ^C в старой манере
signal(SIGINT, endhandler);
// маска блокирования-разблокирования
sigemptyset(&sig);
sigaddset(&sig, SIGNUM);
// блокировка в главном потоке приложения
sigprocmask(SIG_BLOCK, &sig, NULL);
cout << "Process " << getpid() << ", waiting for signal " << SIGNUM << endl;
// установка обработчика (для дочерних потоков)
struct sigaction act;
act.sa_mask = sig;
act.sa_sigaction = handler;
act.sa_flags = SA_SIGINFO;
if (sigaction(SIGNUM, &act, NULL) < 0) perror("set signal handler: ");
const int thrnum = 3;
for (int i = 0; i < thrnum; i++) {
threcord threc = { 0, false };
pthread_create(&threc.tid, NULL, threadfunc, (void*)i);
tharray.push_back(three);
}
pause();
// сюда мы попадаем после ^C для завершающих операций...
tharray.erase(tharray.begin(), tharray.end());
cout << "Clean vector" << endl;
}
Это приложение, в отличие от предыдущих, построено уже с использованием специфики С++, в нем используется контейнерный класс vector из библиотеки STL (Standard Template Library). Может быть множество вариаций на подобную тему. Приведенное нами приложение (как одна из вариаций) только подтверждает, что принятая в QNX модель достаточна для описания самых неожиданных потребностей. Логика работы приложения крайне проста: получая сигнал, поток блокирует повторную реакцию на этот сигнал, после чего возбуждает дубликат полученного сигнала от своего имени.
Примечание
Показанное приложение в значительной степени искусственно и неэффективно. Мы приводим его здесь не как образец того, «как нужно делать», а только как иллюстрацию гибкости возможностей, предоставляемых в области параллельного программирования. При некоторой изобретательности можно заставить программу вести себя согласно вашим капризам, какими бы изощренными они ни оказались.
Запускаем полученное приложение:
# s10
Process 2089006, waiting for signal 41
После чего с другого терминала пошлем приложению ожидаемый им сигнал, например командой:
# kill -41 2089006
Посылаем этот сигнал несколько раз (в данном случае 3) и получаем вывод от приложения:
SIG = 41; TID = 4
SIG = 41; TID = 2
SIG = 41; TID = 3
SIG = 41; TID = 3
SIG = 41; TID = 4
SIG = 41; TID = 2
SIG = 41; TID = 2
SIG = 41; TID = 3
SIG = 41; TID = 4
^C
Clean vector
Видно, что реакция на каждый сигнал возбуждается несколько раз (по числу потоков), каждый раз выполняясь в контексте разного потока (TID). Интересно и изменение порядка активизации потоков от сигнала к сигналу, то есть потоки в очереди ожидающих «перетасовываются» при поступлении каждого сигнала.
Примечание
В приложение добавлена реакция на ^C (сигнал SIGINT ):
• начиная с некоторой сложности приложений, их завершению должна обязательно предшествовать некоторая последовательность действий; в данном случае мы условно показываем очистку вектора состояний потоков;
• реакция на SIGINT выполнена в «ненадежной» манере в смешении с моделью очереди сигналов для SIGRTMIN , что показывает возможность смешанного применения всех моделей в рамках одного приложения; все определяется требованиями и вопросами удобства.
Как мы уже видели, тот факт, что обработчик сигнала выполняется в контексте потока, который разблокировал реакцию на этот сигнал (независимо от того, в момент выполнения какого потока приходит сигнал), позволяет реализовать в обработчике сигнала обработку любой сложности в интересах этого потока. Для этого лишь требуется разместить все области данных, запрашиваемые в этой обработке, не в стеке потока (объявленные как локальные переменные потоковой функции), а в области собственных данных потока, которые мы детально рассмотрели ранее. Схематично это можно показать в коде так:
• Положим, нам нужно уведомлять о некоторых событиях N потоков.
Будем использовать для этого сигналы SIGRTMIN…SIGRTMIN + (N - 1):
for (int i = SIGRTMIN, i < SIGRTMIN + N; i++) {
pthread_create(NULL, NULL, threadfunc, (void*)(i));
}
• При запуске N потоков (из главного потока) потоковые функции, помимо устанавливания своих индивидуальных сигнальных масок (в точности так, как это показано выше в листинге «Чередование потоковых сигналов»), размещают экземпляры собственных потоковых данных:
class DataBlock {
~DataBlock(void) {...}
};
static pthread_key_t key;
static pthread_once_t once = PTHREAD_ONCE_INIT;
static void destructor(void* db) { delete (DataBlock*)db; }
static void once_creator(void) {
pthread_key_create(&key, destructor);
}
void* threadfunc(void* data) {
// надлежащим образом маскируем сигналы
// ...
// это произойдет только в первом потоке из N
pthread_once(&once, once_creator);
DataBlock* pdb = new DataBlock(...);
pthread_setspecific(key, pdb);
// Теперь поток может пользоваться данными *pdb, как и локальными!
// цикл ожидания приходящих сигналов:
while (true) pause();
}
Все потоки используют один и тот же обработчик для всех сигналов; он выполняет одни и те же действия, но над различными объектами данных. Над каким объектом данных выполнить действие, обработчик «узнает» из контекста потока, в котором он выполняется:
static void handler(int signo, siginfo_t* info, void* context) {
DataBlock* pdb = (DataBlock*)pthread_getspecific(key);
// выполняем действия для своего потока ...
}
• Теперь, например из главного потока процесса (главный поток выбран для простоты - источником сигнала может быть произвольный поток, даже не этого процесса), требуемое действие вызывается возбуждением соответствующего сигнала:
sigqueue(getpid(), SIGRTMIN + K, val);
Это только скелетная схема, но на ее основе можно строить развитые протоколы обработки данных (пример взят из работоспособного приложения).
За пределы POSIX: сигналы в сети
А теперь, «на закуску», посмотрим справочную информацию по системной команде kill (послать сигнал). Вы, должно быть, помните, что в QNX есть дополнительная возможность получить справку по любой команде системы, используя команду # use <имя-команды>. Более того, вы можете и в любое свое приложение встроить возможность получения интерактивной справки. Как это происходит, описано в [4]. Итак:
# use kill
kill - terminate or signal processes (POSIX)
kill [-signal_name|-signal_number] pid ...
kill -l
Options:
-signal_name Symbolic name of signal to send
-signal_number Integer representing a signal type
-l List symbolic signal names
-n node Kill processes on the specified node.
(/bin/kill only)
Where:
Valid signal names are:
SIGNULL SIGHUP SIGINT SIGQUIT SIGILL SIGTRAP
SIGIOT SIGABRT SIGEMT SIGFPE SIGKILL SIGBUS
SIGSEGV SIGSYS SIGPIPE SIGALRM SIGTERM SIGUSR1
SIGUSR2 SIGCHLD SIGPWR SIGWINCH SIGURG SIGPOLL SIGSTOP SIGTSTP
SIGCONT SIGVTALARM SIGTTIN SIGTTOU
Note:
kill is also available as a shell builtin
Здесь нас ожидает сюрприз, который мы выделили в показанном фрагменте жирным шрифтом. И говорит эта строка о том, что в системе QNX сигнал может посылаться процессу, работающему на любом узле сети QNET. И это совершенно естественно, если вспомнить промелькнувшее выше замечание из технической документации, что сигнал в QNX - это пульс, то есть один из видов сообщений микроядра.
Таким образом, системная команда QNX kill (именно системная — /bin/kill, в отличие от встроенной формы kill командных интерпретаторов, которые строго следуют традициям UNIX, как и предупреждает выделенная нами строка) имеет возможность посылать сигналы любому процессу в сети. Тем не менее при рассмотрении прототипов вызовов kill() и sigqueue() мы не находим и следа параметра, предоставляющего возможность определить удаленный процесс. Тогда каким образом это делает команда kill? Совершенно верно: используя вызов native QNX API, который выглядит так (этот вызов, как и многие другие, имеет две формы, вторая из которых является безопасной в много- поточной среде):
#include
int SignalKill(uint32_t nd, pid_t pid,
int tid, int signo, int code, int value);
int SignalKill_r(uint32_t nd, pid_t pid, int tid, int signo,
int code int value);
где nd — дескриптор сетевого узла QNET, на котором будут разыскиваться pid и tid. Для посылки сигнала локальному процессу (потоку) можно для nd указать 0, но лучше — определенную системой константу ND_LOCAL_NODE.
Примечание
Дескриптор узла в сети QNET — понятие относительное; он может быть получен, например, вызовом netmgr_strtond() . Но и здесь не все так просто:
• Дескриптор, соответствующий, скажем, узлу «host», полученный на узле «А», может иметь значение N, но дескриптор того же узла, полученный на узле «В», будет иметь уже значение M, то есть дескриптор узла — это «дескриптор сетевого узла X, как он видится с сетевого узла Y».
• Тот же дескриптор узла «host» может быть определен как имеющий значение N, но уже через несколько секунд он может «сменить» свое значение на M, то есть значения, полученные netmgr_strtond() , должны использоваться немедленно...
Эти и другие сложности относятся к особенностям программного использования QNET и требуют отдельного обстоятельного обсуждения. Однако они не являются предметом нашего текущего рассмотрения.
pid — PID процесса, которому направляется сигнал, pid может иметь и отрицательное значение, при этом положительное значение (-pid) идентифицирует группу процессов EGID, и сигнал будет отправлен всем процессам группы. При нулевом значении pid сигнал будет отправлен всем процессам группы процесса отправителя.
tid — 0 или TID потока, которому направляется сигнал. При указании tid сигнал будет доставляться только указанному потоку, а при tid = 0 — всем потокам процесса. Дальнейшая судьба сигнала в обоих случаях зависит от маскирования сигнала в потоке, как мы рассматривали ранее.
signo — номер сигнала (с ним неоднократно встречались выше).
code и value — код и значение, ассоциированные с сигналом (их мы тоже встречали при рассмотрении модели сигналов реального времени).
Как и обычно, внешнее различие (для программиста) основной формы SignalKill() и формы, безопасной в многопоточной среде, SignalKill_r() состоит в том, что:
• SignalKill() возвращает -1 в случае ошибки, а код ошибки заносится в errno; любой другой возврат является индикатором успешного выполнения;
• SignalKill_r() возвращает EOK в случае успеха, а в случае ошибки возвращается отрицательный код ошибки (тот же, который основная форма заносит в errno, но со знаком минус).
Возможны следующие коды ошибок, возвращаемые этими вызовами:
EINVAL — недопустимое числовое значение signo;
ESRCH — несуществующий адресат (pid или tid);
EPERM — процесс не имеет достаточных прав для посылки сигнала;
EAGAIN — недостаточно ресурсов ядра для выполнения запроса.
Для того чтобы получить работающий пример использования этой возможности, возьмите любой из приводившихся выше примеров, разнесите процессы по сетевым узлам и определите «целеуказание» в процессе-отправителе.
Простейшим примером и демонстрацией удаленной реакции в сети может быть следующая последовательность действий:
• Производим запуск задачи на удаленном узле, например:
# on -f
• После чего, выполнив ряд операций в запущенной программе, прекращаем ее работу по [Ctrl+C] с локального терминала.
Интересно оценить далеко идущие последствия этого «маленького» расширения стандартной POSIX-схемы работы с сигналами:
• На технике «сетевых сигналов» может быть построена целая система уведомлений сетевых составляющих компонент единой программной прикладной системы.
• Именно «уведомлений» (но не синхронизации с наследованием приоритетов, влияющей на общую систему диспетчеризации составляющих частей и т.п.): посылка сигнала является неблокирующей операцией (не требует ответа), а прием сигнала не сопровождается наследованием (или любым изменением) приоритетов.
• Такое «сигнальное» взаимодействие, записанное в формальной POSIX-семантике (но, по сути, осуществляющее механизмы, далеко выходящие за POSIX), может оказаться гораздо проще в записи и понимании, чем при использовании низкоуровневых механизмов обмена сообщениями (пульсами).