К сожалению, именно такая модель сигналов используется в ANSI/ISO-стандарте С[55]. Хотя программные интерфейсы надежных сигналов, в которых исправлен этот недостаток, уже широко распространены, стандартизация ненадежных сигналов в ANSI/ISO, видимо, останется навсегда.
Реализация BSD для решения проблемы множества сигналов полагается на простое ожидание завершения работы каждого обработчика сигналов в процессе перед доставкой следующего. Это гарантирует то, что каждый сигнал будет рано или поздно обработан, а также исключает риск переполнения стека. Вспомним, что когда ядро удерживает сигнал для отложенной доставки, сигнал называется ожидающим (pending).
Однако если процессу отправлен сигнал SIGЧТО-ТО, в то время, как SIGЧТО-ТО уже находится в состоянии ожидания, то в этом случае процессу доставляется только первый из них. У процесса нет никакой возможности узнать, сколько раз один и тот же сигнал был отправлен ему, поскольку множество одинаковых сигналов подряд воспринимаются как один. Обычно это не представляет собой проблему. Поскольку сигнал не несет в себе никакой информации помимо собственно номера сигнала, двойная посылка сигнала за очень короткий отрезок времени может быть воспринята как одиночная, потому если программа примет сигнал только однажды, это не имеет особого значения. Это отличается от варианта с обработкой второго сигнала по умолчанию (что делается при ненадежной схеме обработки сигналов)[56].
Идея об автоматической блокировке сигналов была расширена для того, чтобы позволить процессам блокировать сигналы явным образом. Это облегчает защиту критичных участков кода, в то же время гарантируя обработку всех отправленных сигналов. Такая защита позволяет обработчикам сигналов манипулировать структурами данных, которые поддерживаются другими участками кода, за счет простой синхронизации.
Хотя BSD представляет адаптированную версию модели сигналов POSIX, комитет по стандартизации POSIX упростил ее для системных вызовов, с тем чтобы модифицировать диспозицию групп сигналов, предлагая новые системные вызовы для оперирования наборами сигналов. Наборы сигналов представлены типом данных sigset_t, и для манипулирования ими предусмотрен набор макросов[57].
12.1.4. Сигналы и системные вызовы
Часто сигналы доставляются процессу, который находится состоянии ожидания наступления некоторого внешнего события. Например, текстовый редактор часто ожидает завершения read(), чтобы возвратить ввод терминала. Когда системный администратор посылает процессу сигнал SIGTERM (нормальный сигнал, посылаемый командой kill, позволяющий процессу завершиться чисто), то процесс может обработать его, как описано ниже.
1. Не пытаться перехватить сигнал и быть прерванным ядром (обработка SIGTERM по умолчанию). Это оставляет пользовательский терминал в нестандартной конфигурации, затрудняя ему продолжение работы.
2. Перехватить сигнал, очистить терминал с помощью обработчика этого сигнала, затем выйти. Хотя это кажется привлекательным, в сложных программах трудно написать такой обработчик, который знал бы достаточно о том, что делает программа в момент прерывания, чтобы правильно выполнить очистку.
3. Перехватить сигнал, установить флаг, обозначающий, что сигнал получен, и каким-то образом обеспечить выход из блокирующего системного вызова (в данном случае read()) с индикацией ошибки — в знак того, что произошло что-то необычное. Нормальный порядок выполнения затем должен проверить флаг и обработать его соответствующим образом.
Поскольку последний вариант выглядит намного чище и легче остальных, оригинальная реализация сигналов заставляет медленные системные вызовы возвратить EINTR, когда они прерываются сигналом, в то время как быстрые системные вызовы завершаются перед тем, как сигнал будет доставлен.
Медленные системные вызовы требуют неопределенного времени для своего завершения. Системные вызовы, которые для завершения своей работы ожидают непредсказуемых ресурсов, таких как другие процессы, сетевые данные либо действия со стороны человека, рассматриваются как медленные. Семейство системных вызовов wait(), например, не возвращают управление до тех пор, пока дочерние процессы не завершатся. Поскольку невозможно узнать, насколько долго продлится это ожидание, считается, что wait() — медленный системный вызов. Системные вызовы доступа к файлам рассматриваются как медленные, если они обращаются к медленным файлам, и быстрые — если к быстрым файлам[58].
Обязанностью процесса является обработка EINTR и перезапуск системных вызовов в случае необходимости. Хотя это обеспечивает всю функциональность, которая требуется людям, намного сложнее написать код, который обрабатывает сигналы. Всякий раз когда read() вызывается на медленном файловом дескрипторе, код должен проверять его возврат на равенство EINTR, и перезапускать вызов, либо он не будет делать то, что ожидается.
Чтобы "упростить" ситуацию, 4.2BSD автоматически перезапускает такие системные вызовы (особенно read() и write()). Поэтому для большинства операций программы более не должны беспокоиться об EINTR, поскольку выполнение системных вызовов продолжится после того, как процесс обработает сигнал. В последних версиях Unix изменен перечень системных вызовов, которые автоматически перезапускаются, a 4.3BSD позволяет вам выбрать, какие системные вызовы перезапускать. Стандарт обработки сигналов POSIX не указывает, какое поведение должно применяться, но все популярные системы согласны в том, как обрабатывать этот случай. По умолчанию системные вызовы не перезапускаются, но для каждого сигнала процесс может установить флаг, который указывает, что система должна перезапускать системные вызовы, прерванные этим сигналом.
12.2. Программный интерфейс сигналов Linux и POSIX
Посылка сигналов от одного процесса другому обычно осуществляется с помощью системного вызова kill(). Этот системный вызов подробно обсуждался в главе 10. Вариантом kill() является tkill(), который не предназначен для прямого использования в программах.
int tkill(pid_t pid, int signum);
Существуют два отличия между kill() и tkill()[59]. Первое: pid должен быть положительным числом; tkill() не может использоваться для отправки сигналов группам процессов, как это может kill(). Другое отличие позволяет обработчикам сигналов определять, применялся ли вызов kill() или tkill() для генерации сигнала: подробности см. далее в главе.
Функция raise(), которая представляет собой способ генерации сигналов, указанный ANSI/ISO, использует системный вызов tkill() для генерации сигналов в системах Linux.
int raise(int signum);
Функция raise() посылает текущему процессу сигнал, указанный в signum[60].
12.2.2. Использование sigset_t
Большинство функций сигналов POSIX принимают набор сигналов в качестве одного из своих параметров (или части одного из параметров). Тип данных sigset_t служит для представления набора сигналов и определен в <signal.h>. POSIX определяет пять функций для манипулирования наборами сигналов.
#include <signal.h>
int sigemptyset(sigset_t *set);
int sigfillset(sigset_t *set);
int sigaddset(sigset_t *set, int signum);
int sigdelset(sigset_t *set, int signum);
int sigismember(const sigset_t *set, int signum);
int sigemptyset(sigset_t *set); Делает пустым набор сигналов, на который указывает set (никаких сигналов в set представлено не будет). int sigfillset(sigset_t *set); Включает все доступные сигналы в set. int sigaddset(sigset_t *set, int signum); Добавляет сигнал signum в набор set. int sigdelset(sigset_t *set, int signum); Удаляет сигнал signum из набора set. int sigismember(const sigset_t *set, int signum); Возвращает не 0, если сигнал signum содержится в set. В противном случае возвращает 0.
Единственной причиной возврата ошибки любой из этих функций может быть то, что параметр signum будет содержать неправильный номер сигнала. В этом случае возвращается EINVAL. Излишне говорить, что подобное никогда не должно случаться.
