• Ядро ведет учет сигналов, которые ожидают доставки как в процесс целиком, так и в каждый отдельный его поток. Вызов sigpending() возвращает объединенный список сигналов, ожидающих доставки в процесс и вызывающий поток. Сразу после создания потока список сигналов, которые должны быть ему доставлены, является пустым. Сигнал, направленный в поток, может быть доставлен только этому потоку. Если сигнал блокируется потоком, он будет оставаться в состоянии ожидания до тех пор, пока поток его не разблокирует (или не завершится).
• Если вызов pthread_mutex_lock() прерывается обработчиком сигнала, он всегда автоматически перезапускается. Вызов pthread_mutex_lock(), прерванный обработчиком сигнала, либо автоматически перезапускается (как это делается в Linux), либо возвращает 0, что свидетельствует о ложном срабатывании (в этом случае хорошо спроектированное приложение должно повторно проверить соответствующий предикат и перезапустить вызов, как описано в подразделе 30.2.3). Поведение, описанное выше, предусмотрено стандартом SUSv3.
• Альтернативный стек сигналов относится к каждому отдельному потоку (см. описание вызова sigaltstack() в разделе 21.3). Новый поток не наследует альтернативный стек сигналов от своего создателя.
Если быть более точным, стандарт SUSv3 гласит, что отдельный альтернативный стек сигналов выделяется для каждой единицы планирования ядра (Kernel Scheduling Entity или KSE). В системах, в которых потоки реализованы в соответствии с моделью 1:1 (как, например, в Linux), каждому потоку соответствует один экземпляр KSE.
33.2.2. Изменение масок сигналов потока
Новый поток наследует от своего создателя копию сигнальной маски. Изменить и/или извлечь эту маску он может с помощью вызова pthread_sigmask().
#include
int pthread_sigmask(int
Возвращает 0 при успешном завершении или положительное число, если произошла ошибка
Если не принимать во внимание тот факт, что функция pthread_sigmask() работает с сигнальной маской потока, ее использование ничем не отличается от вызова sigprocmask() (см. раздел 20.10).
В стандарте SUSv3 отмечается, что применение вызова sigprocmask() внутри многопоточной программы является неопределенным. Этот вызов нельзя использовать в переносимых многопоточных приложениях. Хотя на практике sigprocmask() и pthread_sigmask() идентичны во многих системах, включая Linux.
33.2.3. Отправка сигнала потоку
Функция pthread_kill() отправляет сигнал sig другому потоку в том же процессе. Целевой поток определяется аргументом thread.
#include
int pthread_kill(pthread_t
Возвращает 0 при успешном завершении или положительное число, если произошла ошибка
Поскольку идентификатор потока уникален только в рамках одного процесса (см. раздел 29.5), мы не можем использовать функцию pthread_kill() для отправки сигнала потоку из другого процесса.
Функция pthread_kill() реализована с применением системного вызова tgkill(tgid, tid, sig), который доступен только в Linux. Этот вызов отправляет сигнал sig потоку, определяемому по аргументу tid (идентификатору потока ядра, который имеет такой же тип, как тот, что возвращается вызовом gettid()) в рамках группы потоков с идентификатором tgid. Больше подробностей ищите на справочной странице tgkill(2).
Функция pthread_sigqueue(), доступная только в Linux, сочетает в себе возможности pthread_kill() и sigqueue() (см. подраздел 22.8.1): она отправляет сигнал с сопутствующими данными другому потоку в том же процессе.
#define _GNU_SOURCE
#include
int pthread_sigqueue(pthread_t
Возвращает 0 при успешном завершении или положительное число, если случилась ошибка
Как и в случае с pthread_kill(), аргумент sig определяет сигнал, который нужно отправить, а thread — поток-адресат. Аргумент value содержит данные, которые сопровождают сигнал; он используется так же, как одноименный аргумент в вызове sigqueue().
Функция pthread_sigqueue() была добавлена в библиотеку glibc в версии 2.11 и требует поддержки на уровне ядра. Эта поддержка предоставляется за счет системного вызова rt_tgsigqueueinfo(), который появился в Linux 2.6.31.
33.2.4. Разумная обработка асинхронных сигналов
В главах 20–22 мы обсуждали различные факторы, которые способны затруднить работу с асинхронно генерируемыми сигналами посредством обработчиков — например, проблемы с реентерабельностью, необходимость перезапуска прерванных системных вызовов и предотвращение состояния гонки. К этому можно добавить, что ни одну функцию из состава Pthreads нельзя безопасно вызвать внутри обработчика сигнала (см. подраздел 21.1.2). В связи с этим многопоточные программы, сталкивающиеся с асинхронно генерируемыми сигналами, обычно не должны оповещать о доставке сигналов с помощью их обработчиков. Рекомендуется использовать следующий подход.
