BSD 4.0 (примерно с 1980 г.) ввел дополнительные функции API для предоставления «надежных» сигналов. [109] В частности, стало возможным блокировать сигналы. Другими словами, программа могла сообщить ядру: «Зависни на этих конкретных сигналах в течении следующего небольшого промежутка времени, затем доставь их мне, когда я буду готов их принять». Большим преимуществом является то, что эта особенность упрощает обработчики сигналов, которые автоматически запускаются со своим заблокированным сигналом (чтобы избежать проблемы одновременной
обработки двух сигналов) и, возможно, также и с другими заблокированными сигналами.
109
Для использования API требуется компоновка с отдельной библиотекой, —
ljobs
— Примеч. автора.
System V Release 3 (примерно с 1984 г.) приняла эти API и популяризовала их, в большинстве связанных с Unix документации и книгах вы, возможно, увидите, что на эти API ссылаются, как ведущие начало от System V Release 3. Эти функции следующие:
#include <signal.h> /* XSI */
int sighold(int sig); /* Добавить sig к маске сигналов процесса */
int sigrelse(int sig); /* Удалить sig из маски сигналов процесса */
int sigignore(int sig); /* Сокращение для sigset(sig, SIG_IGN) */
int sigpause(int sig);
/* Приостановить процесс, позволить появиться sig */
Стандарт POSIX для этих функций описывает их поведение в терминах маски сигналов процесса. Маска сигналов процесса отслеживает, какие сигналы (если они вообще есть) процесс заблокировал в настоящее время. Более подробно это описывается в разделе 10.6.2 «Наборы сигналов:
sigset_t
и связанные функции». В API System V Release 3 нет способа получить или изменить маску сигналов процесса в целом. Функции работают следующим образом:
int sighold(int sig)
Добавляет
sig
к списку заблокированных процессов (маска сигналов процесса).
int sigrelse(int sig)
Удаляет
sig
из маски сигналов процесса.
int sigignore(int sig)
Игнорирует
sig
. Это вспомогательная функция.
int sigpause(int sig)
Удаляет
sig
из маски сигналов процесса, а затем приостанавливает процесс до появления сигнала (см. раздел 10.7 «Сигналы для межпроцессного взаимодействия»).
sighandler_t sigset(int sig, sighandler_t disp)
Это замена для signal. (Здесь мы использовали обозначение из справочной страницы GNU/Linux, чтобы упростить восприятие объявления функции.)
Для
sigset
аргумент
handler
может быть
SIG_DFL
,
SIG_IGN
или указатель функции, как и для
signal
. Однако, он может равняться также и
SIG_HOLD
. В этом случае
sig
добавляется к маске сигналов процесса, но связанное с ним действие никак не изменяется. (Другими словами, если бы у него был обработчик, он остается тем же; если было действие по умолчанию, оно не изменяется.)
Когда для установки обработчика сигнала используется
sigset
и появляется сигнал, ядро сначала добавляет сигнал к маске процессов сигнала, блокируя любой дальнейший прием этого сигнала.
Запускается обработчик, а когда он возвращается, ядро восстанавливает маску сигналов процесса в то состояние, какое было до запуска обработчика. (В модели POSIX если обработчик сигнала изменяет маску сигнала, это изменение переписывается в процессе восстановления предыдущей маски, когда обработчик возвращается.)
sighold
и
sigrelse
могут использоваться совместно для выделения так называемых критических секций кода: участков кода, который не должен прерываться определенным сигналом, чтобы структуры данных не повреждались кодом обработчика сигнала.
ЗАМЕЧАНИЕ. POSIX стандартизует эти API, поскольку главной целью POSIX является формализация существующей практики, где это возможно. Однако, функции
sigaction
, которые вскоре будут описаны, дают вам все, что делают эти API, и даже больше. В новых программах вам не следует использовать эти API Вместо этого используйте
sigaction
. (Мы заметили, что в справочной системе GNU/Linux нет даже страницы для sigset(2)!)
10.6. Сигналы POSIX
API POSIX основан на API
sigvec
из BSD 4.2 и 4.3. С небольшими изменениями этот API можно было отнести к возможностям API как V7, так и System V Release 3. POSIX сделал эти изменения и переименовал API
sigaction
. Поскольку интерфейс
sigvec
широко не использовался, мы не будем его описывать. Вместо этого в данном разделе описывается только
sigaction
, который вы и должны так или иначе использовать. (На самом деле руководства BSD 4.4 от 1994 г. помечают
sigvec
как устаревшую, указывая читателю на
sigaction
.)
10.6.1. Обнажение проблемы
Что неладно с API System V Release 3? В конце концов, они предоставляют блокирование сигналов, так, что сигналы не теряются, и любой данный сигнал может быть надежно обработан.
Ответ в том, что этот API работает лишь с одним сигналом в одно и то же время. Программы обычно обрабатывают больше одного сигнала. И когда вы находитесь в середине процесса обработки одного сигнала, вы не хотите беспокоиться по поводу обработки еще и второго. (Предположим, вы только что начали отвечать по офисному телефону, когда зазвонил ваш мобильный телефон: вы бы предпочли, чтобы телефонная система ответила вызывающему, что в данный момент вы находитесь на другой линии и что скоро освободитесь, вместо того, чтобы проделывать все это самому.)
С API
sigset
каждый обработчик сигнала должен был бы временно блокировать все другие сигналы, сделать свою работу, а затем разблокировать их. Проблема в том, что в промежутке между любыми двумя вызовами
sighold
может появиться еще не заблокированный сигнал. Сценарий, еще раз, распространенный, создающий условия гонки.
Решением является обеспечение возможности автоматической работы с группами сигналов, т.е. с помощью одного системного вызова. Вы достигаете этого, работая с наборами сигналов и маской сигналов процесса.
10.6.2. Наборы сигналов:
sigset_t
и связанные функции
Маска сигналов процесса является списком сигналов, которые процесс в настоящее время заблокировал. Сила POSIX API в том, что маской сигналов процесса можно манипулировать атомарно, как единым целым.
Маска сигналов процесса программно представляется с помощью набора сигналов. Это тип
sigset_t
. Концептуально он представляет собой просто битовую маску, причем значения 0 и 1 представляют отсутствие или наличие определенного сигнала в маске.