Как мы уже видели, тот факт, что обработчик сигнала выполняется в контексте потока, который разблокировал реакцию на этот сигнал (независимо от того, в момент выполнения какого потока приходит сигнал), позволяет реализовать в обработчике сигнала обработку любой сложности в интересах этого потока. Для этого лишь требуется разместить все области данных, запрашиваемые в этой обработке, не в стеке потока (объявленные как локальные переменные потоковой функции), а в области собственных данных потока, которые мы детально рассмотрели ранее. Схематично это можно показать в коде так:
• Положим, нам нужно уведомлять о некоторых событиях 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, который выглядит так (этот вызов, как и многие другие, имеет две формы, вторая из которых является безопасной в много- поточной среде):
Читать дальше
Конец ознакомительного отрывка
Купить книгу