Читаем Linux API. Исчерпывающее руководство полностью

Возвращает 0 при успешном завершении или –1 при ошибке

Функция sigvec() — аналог функции sigaction(). Аргументы vec и ovec — это указатели на структуры следующего типа:

struct sigvec {

void (*sv_handler)(int);

int sv_mask;

int sv_flags;

};

Поля структуры sigvec соответствуют полям структуры sigaction. Первое заметное отличие в том, что поле sv_mask раньше было целочисленным, а не типа sigset_t. Это означает, что на 32-битных архитектурах максимально можно было реализовать 31 сигнал. Еще одно отличие — в использовании флага SV_INTERRUPT в поле sv_flags (аналог sa_flags). Поскольку перезапуск системных вызовов был настройкой по умолчанию в 4.2BSD, установка этого флага означала, что медленные системные вызовы должны прерываться обработчиками сигналов. (Это кардинальным образом отличается от функций POSIX API, в случае использования которых мы должны явно устанавливать флаг SA_RESTART для включения перезапуска системных вызовов при установке обработчика сигнала с помощью функции sigaction().)

#define _BSD_SOURCE

#include

int sigblock(int mask);

int sigsetmask(int mask);

Обе функции возвращают предыдущую сигнальную маску

int sigpause(int sigmask);

Всегда возвращает –1 с установкой errno значения EINTR

int sigmask(int sig);

Возвращает значение сигнальной маски с битовым набором sig

Функция sigblock() добавляет набор сигналов в сигнальную маску процесса. Эта функция аналогична операции sigprocmask() SIG_BLOCK. Вызов sigsetmask() устанавливает абсолютное значение сигнальной маски. Эта функция аналогична операции sigprocmask() SIG_SETMASK.

Функция sigpause() аналогична функции sigsuspend(). В GNU библиотеке C по умолчанию предоставляется версия функции из системы System V, если мы не укажем макрос проверки возможностей _BSD_SOURCE при компиляции программы.

Макрос sigmask() преобразует номер сигнала в соответствующее значение 32-битной маски. Такие битовые маски могут быть объединены вместе с помощью логического оператора ИЛИ для создания набора сигналов, как показано в следующем примере:

sigblock(sigmask(SIGINT) | sigmask(SIGQUIT));

22.14. Резюме

Некоторые сигналы приводят к завершению процесса с созданием файла дампа ядра. Этот файл содержит информацию о состоянии процесса на момент завершения, которая может использоваться отладчиком. По умолчанию имя файла дампа ядра — core, но в Linux предоставляется файл /proc/sys/kernel/core_pattern для управления именованием файлов дампа.

Сигнал может быть сгенерирован синхронно и асинхронно. Асинхронная генерация происходит, когда сигнал отправляется процессу ядром или другим процессом. Процесс не может точно предсказать, когда в него будет доставлен сигнал, сгенерированный асинхронно. (Уже отмечалось, что, как правило, асинхронные сигналы доставляются в следующий раз, когда процесс-получатель переключается из режима ядра в режим пользователя.) Синхронная генерация происходит, когда сам процесс выполняет код, напрямую генерирующий сигнал, например, при выполнении кода, вызывающего аппаратное исключение или при вызове функции raise(). Доставку сигнала, генерируемого синхронно, можно предсказать с высокой точностью (она происходит мгновенно).

Сигналы реального времени — надстройка POSIX на исходную модель сигналов. Они отличаются от стандартных тем, что могут быть поставлены в очередь, имеют определенную очередность доставки, а также тем, что могут быть отправлены с сопровождающими данными. Сигналы реального времени предназначены для использования в целях, определяемых приложением. Отправка сигнала реального времени происходит с помощью системного вызова sigqueue(), а через дополнительный аргумент (структура siginfo_t), переданный обработчику сигнала, можно получить данные, сопровождающие сигнал, а также идентификатор процесса и реальный идентификатор пользователя процесса-отправителя.

Системный вызов sigsuspend() позволяет программе автоматически изменять сигнальную маску процесса и приостанавливать выполнение до прибытия сигнала. Атомарность функции sigsuspend() является ее неотъемлемой характеристикой, позволяющей избежать возникновения состояний гонки при разблокировании сигнала и последующей приостановки выполнения до прибытия сигнала.

Как и функции sigwaitinfo() и sigtimedwait(), специфичный системный вызов Linux signalfd() может использоваться для синхронного ожидания сигнала. Отличительной особенностью этого интерфейса является то, что сигналы могут быть прочитаны через файловый дескриптор. Над файловым дескриптором можно осуществлять мониторинг с помощью функций select(), poll() и epoll().

Хотя сигналы могут рассматриваться в качестве метода взаимодействия процессов (IPC), по причине многих факторов сигналы не подходят для этих целей: из-за их асинхронной природы, из-за того, что сигналы не ставятся в очередь, и из-за их низкой пропускной способности. Чаще всего, сигналы используются для синхронизации процессов и для других целей (например, оповещение о событии, управление заданиями, истечение таймера).