10.5. API сигналов System V Release 3: sigset() и др.
10.5. API сигналов System V Release 3: sigset() и др.
BSD 4.0 (примерно с 1980 г.) ввел дополнительные функции API для предоставления «надежных» сигналов.[109] В частности, стало возможным блокировать сигналы. Другими словами, программа могла сообщить ядру: «Зависни на этих конкретных сигналах в течении следующего небольшого промежутка времени, затем доставь их мне, когда я буду готов их принять». Большим преимуществом является то, что эта особенность упрощает обработчики сигналов, которые автоматически запускаются со своим заблокированным сигналом (чтобы избежать проблемы одновременной обработки двух сигналов) и, возможно, также и с другими заблокированными сигналами.
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 */
void (*sigset(int sig, void (*disp)(int)))(int);
/* sighandler_t sigset(int sig, sighandler_t disp); */
Стандарт 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)!)
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКЧитайте также
10.2. Действия сигналов
10.2. Действия сигналов Каждый сигнал (вскоре мы представим полный список) имеет связанное с ним действие по умолчанию. POSIX обозначает это как диспозицию (disposition) сигнала. Это то действие, которое ядро осуществляет для процесса, когда поступает определенный сигнал. Действие
10.4.3. Игнорирование сигналов
10.4.3. Игнорирование сигналов Более практично, когда вызывается обработчик сигнала, это означает, что программа должна завершиться и выйти. Было бы раздражающим, если бы большинство программ по получении SIGINT выводили бы сообщение и продолжали работу; смысл сигнала в том,
12.1. Концепция сигналов
12.1. Концепция сигналов 12.1.1. Жизненный цикл сигнала Сигналы имеют четко определенный жизненный цикл: они создаются, сохраняются до тех пор, пока ядро не выполнит определенное действие на основе сигнала, а затем вызывают совершение этого действия. Создание сигнала
12.2.1. Посылка сигналов
12.2.1. Посылка сигналов Посылка сигналов от одного процесса другому обычно осуществляется с помощью системного вызова kill(). Этот системный вызов подробно обсуждался в главе 10. Вариантом kill() является tkill(), который не предназначен для прямого использования в программах.int
12.2.3. Перехват сигналов
12.2.3. Перехват сигналов Вместо использования функции signal() (чья семантика в процессе эволюции стала неправильной) POSIX-программы регистрируют обработчики сигналов с помощью sigaction().#include <signal.h>int sigaction(int signum, struct sigaction *act, struct sigaction *oact);Этот системный вызов устанавливает
12.2.6. Ожидание сигналов
12.2.6. Ожидание сигналов Когда программа построена преимущественно вокруг сигналов, часто необходимо, чтобы она ожидала появления какого-то сигнала, прежде чем продолжать работу. Системный вызов pause() предоставляет простую возможность для этого.#include <unistd.h>int
12.3.1. Описание сигналов
12.3.1. Описание сигналов Иногда приложения нуждаются в описании сигнала для отображения пользователю или помещения в журнал. Существуют три способа сделать это (см. главу 9). К сожалению, ни один из них не стандартизован.Самый старый метод предусматривает применение sys_siglist
System V Release 4 (SVR4)
System V Release 4 (SVR4) В 1989 году была выпущена новая основная версия — System V Release 4. По существу она объединила возможности нескольких известных версий UNIX: SunOS фирмы Sun Microsystems, BSD UNIX компании Berkeley Software Distribution и предыдущих версий System V.Новые черты системы включали:? Командные
7.2.1 Обработка сигналов
7.2.1 Обработка сигналов Ядро обрабатывает сигналы в контексте того процесса, который получает их, поэтому чтобы обработать сигналы, нужно запустить процесс. Существует три способа обработки сигналов: процесс завершается по получении сигнала, не обращает внимание на
23.3.4. Обработка сигналов
23.3.4. Обработка сигналов Перед тем, как перейти к следующему пункту, нужно еще раз рассмотреть функцию gtk_signal_connect(). Данной функции нужно передать четыре параметра:? GtkObject *object — объект, которому может быть послан сигнал;? const gchar *name — имя сигнала, например, «destroy»;? GtkSignalFunc func
Перехват сигналов
Перехват сигналов Вы можете использовать встроенную в bash программу trap для перехвата сигналов в своих программах. Это хороший способ изящно завершать работу программы. Например, если пользователь, когда ваша программа работает, нажмет CTRL-C — программе будет отправлен
System.DateTime и System.TimeSpan
System.DateTime и System.TimeSpan В завершение нашего обзора базовых типов данных позволите обратить ваше внимание на то, что пространство имен System определяет несколько полезных типов данных, для которых в C# не предусмотрено ключевых слов. Это, в частности, типы DateTime и TimeSpan (задачу
Базовые классы System.MulticastDelegate и System.Delegate
Базовые классы System.MulticastDelegate и System.Delegate Таким образом, при создании типов c помощью) ключевого слова delegate в C# вы неявно объявляете тип класса, являющегося производным от System.MulticastDelegate. Этот класс обеспечивает своим потомкам доступ к списку с адресами тех методов, которые
4.5.1. Обработка сигналов
4.5.1. Обработка сигналов Предположим, что многопотоковая программа принимает сигнал. В каком потоке будет вызван обработчик сигнала? Это зависит от версии UNIX. В Linux поведение программы объясняется тем. что потоки на самом деле реализуются в виде процессов.Каждый поток в Linux
Приложение В Таблица сигналов
Приложение В Таблица сигналов В табл. В.1 перечислены сигналы, которые чаще всего приходится обрабатывать в Linux-программах. Некоторые сигналы имеют разные интерпретации в зависимости от того, где они были получены.Указанные имена сигналов определены в виде макроконстант
26.3.4. Игнорирование сигналов
26.3.4. Игнорирование сигналов Когда пользователь регистрируется в системе, просматривается файл /etc/profile; нежелательно, чтобы пользователь прерывал этот процесс. Обычно задается перехват, или игнорирование, сигналов 1, 2, 3 и 15, но потом при просмотре сообщения motd (ежедневного