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

Как отмечалось в разделе 22.5, синхронно генерируемые сигналы доставляются незамедлительно. Например, аппаратное исключение приводит к немедленной генерации сигнала, а когда процесс посылает самому себе сигнал с помощью функции raise(), то сигнал доставляется перед тем, как происходит возврат из вызова raise().

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

• когда процесс заново запланирован после предшествующего тайм-аута (то есть в начале тайм-слота);

• по завершении системного вызова (доставка сигнала может привести к преждевременному завершению блокирующего системного вызова).

Очередность доставки нескольких разблокированных сигналов

Если несколько сигналов ожидают доставки в процесс и были одновременно разблокированы функцией sigprocmask(), то все эти сигналы будут незамедлительно доставлены в процесс.

В текущих версиях реализаций ядро Linux доставляет сигналы в порядке возрастания. Например, при одновременном разблокировании сигналов SIGINT (сигнал 2) и SIGQUIT (сигнал 3) сигнал SIGINT будет доставлен раньше, чем сигнал SIGQUIT вне зависимости от того, в какой последовательности эти сигналы были сгенерированы.

Впрочем, мы не можем всецело полагаться на то, что (стандартные) сигналы будут доставляться в какой-то конкретной очередности, так как согласно стандарту SUSv3 очередность доставки нескольких сигналов зависит от реализации системы. (Это высказывание действительно только для стандартных сигналов. Как мы увидим в разделе 22.8, стандарты, специфицирующие сигналы реального времени, гарантируют очередность доставки нескольких разблокированных сигналов реального времени.)

В случаях, когда несколько разблокированных сигналов ожидают доставки, если переключение между режимами ядра и пользователя происходит во время выполнения обработчика, то выполнение этого обработчика будет прервано активацией второго обработчика сигнала (и т. д.), как показано на рис. 22.1.

Рис. 22.1.Доставка нескольких разблокированных сигналов

22.7. Реализация и переносимость функции signal()

В этом разделе будет показано, как реализовать функцию signal() через функцию sigaction(). Реализация прямолинейна, однако следует учесть тот факт, что исторически и в разных реализациях UNIX семантика функции signal() была различной. В частности, ранние реализации сигналов были ненадежными, а это означало следующее.

• По входу в обработчик сигнала диспозиция этого сигнала сбрасывалась до значения по умолчанию. (Это соответствует флагу SA_RESETHAND, описанному в разделе 20.13.) Чтобы при повторной доставке этого же сигнала был активирован обработчик сигнала, программист должен вызывать signal() внутри обработчика, и тогда обработчик явным образом переустановится. Проблема такого подхода заключается в наличии небольшого временного промежутка между входом в обработчик и переустановкой обработчика. Если сигнал прибывает как раз в этот промежуток, то он будет обработан в соответствии с диспозицией по умолчанию.

• Доставка последующих копий сигнала не блокировалась во время выполнения обработчика сигнала. (Соответствует флагу SA_NODEFER, описанному в разделе 20.13.) Это означало, что если сигнал был повторно доставлен во время выполнения обработчика, то происходила рекурсивная активация обработчика. При достаточно интенсивном потоке сигналов происходящие рекурсивные активации могли переполнять стек.

В добавок к ненадежности ранние версии UNIX не предоставляли автоматический перезапуск системных вызовов (иными словами, поведение, описанное для флага SA_RESTART в разделе 21.5).

Надежные сигналы 4.2BSD сняли эти ограничения, чему также последовали некоторые другие реализации UNIX. Однако старая семантика сохраняется и сегодня в реализации функции signal() в System V, более того, в современных стандартах, таких как SUSv3 и С99, эти аспекты намеренно не специфицированы.

Соединяя все вышесказанное, мы реализуем функцию signal() как показано в листинге 22.1. По умолчанию эта реализация предоставляет современную семантику сигналов. При компиляции с опцией — DOLD_SIGNAL эта реализация предоставит раннюю ненадежную семантику сигналов, автоматический перезапуск системных вызовов также будет отключен.

Листинг 22.1. Реализация функции signal()

signals/signal.c

#include

typedef void (*sighandler_t)(int);

sighandler_t

signal(int sig, sighandler_t handler)

{

struct sigaction newDisp, prevDisp;

newDisp.sa_handler = handler;

sigemptyset(&newDisp.sa_mask);