Все потоки используют один и тот же обработчик для всех сигналов; он выполняет одни и те же действия, но над различными объектами данных. Над каким объектом данных выполнить действие, обработчик «узнает» из контекста потока, в котором он выполняется:
Теперь, например из главного потока процесса (главный поток выбран для простоты - источником сигнала может быть произвольный поток, даже не этого процесса), требуемое действие вызывается возбуждением соответствующего сигнала:
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
Здесь нас ожидает сюрприз, который мы выделили в показанном фрагменте жирным шрифтом. И говорит эта строка о том, что в системе QNX сигнал может посылаться процессу, работающему на любом узле сети QNET. И это совершенно естественно, если вспомнить промелькнувшее выше замечание из технической документации, что сигнал в QNX - это пульс, то есть один из видов сообщений микроядра.
Таким образом, системная команда QNX
kill
(именно
системная — /bin/kill, в отличие от встроенной формы
kill
командных интерпретаторов, которые строго следуют традициям UNIX, как и предупреждает выделенная нами строка) имеет возможность посылать сигналы любому процессу в сети. Тем не менее при рассмотрении прототипов вызовов
kill
и
sigqueue
мы не находим и следа параметра, предоставляющего возможность определить удаленный процесс. Тогда каким образом это делает команда
kill
? Совершенно верно: используя вызов native QNX API, который выглядит так (этот вызов, как и многие другие, имеет две формы, вторая из которых является безопасной в много- поточной среде):
#include <sys/neutrino.h>
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 — всем потокам процесса. Дальнейшая судьба сигнала в обоих случаях зависит от маскирования сигнала в потоке, как мы рассматривали ранее.