Linux программирование в примерах

Роббинс Арнольд

• Действия, происходящие после возвращения из обработчика, варьируют в зависимости от системы. Традиционные системы (V7, Solaris, возможно, и другие) восстанавливают действие сигнала по умолчанию. На этих системах прерванный системный вызов возвращает -1, устанавливая в

errno

значение

EINTR

. Системы BSD оставляют обработчик установленным и возвращают -1 с

errno

, содержащим

EINTR

, лишь в случае, когда не было перемещения данных; в противном случае, системный вызов запускается повторно.

• GNU/Linux придерживается POSIX, который похож, но не идентичен с BSD. Если не было перемещения

данных, системный вызов возвращает -1/

EINTR

. В противном случае он возвращает объем перемещенных данных. Поведение BSD «всегда повторный запуск» доступно через интерфейс

sigaction

, но он не является действием по умолчанию.

• Обработчики сигналов, используемые с

signal

, подвержены состояниям гонок. Внутри обработчиков сигналов должны использоваться исключительно переменные типа

volatile sig_atomic_t

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

• Первоначальной попыткой создания надежных сигналов был API сигналов System V Release 3 (скопированный из BSD 4.0). Не используйте его в новом коде.

• POSIX API содержит множество компонентов:

• маску сигналов процесса, перечисляющую текущие заблокированные сигналы;

• тип

sigset_t

для представления масок сигналов, и функции

sigfillset

,

sigemptyset

,

sigaddset

,

sigdelset

и

sigismember

для работы с ними;

• функцию

sigprocmask

для установки и получения маски сигналов процесса,

• функцию

sigpending

для получения набора ожидающих сигналов;

• API

sigaction

и

struct sigaction

во всем их великолепии.

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

siginfo_t

).

• Механизмами POSIX для посылки сигналов являются

kill

и

killpg

. Они отличаются от

raise

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

• Сигналы могут использоваться в качестве механизма IPC, хотя такой способ является плохим способом структурирования приложения, подверженным состояниям гонок. Если кто-то держит приставленным к вашей голове ружье, чтобы заставить вас работать таким способом, для правильной работы используйте тщательное блокирование сигналов и интерфейс

sigaction

.

• 

SIGALARM

и системный вызов

alarm

предоставляют низкоуровневый механизм для уведомления о прошествии определенного числа секунд,

pause

приостанавливает процесс, пока не появятся какие-нибудь сигналы,

sleep

использует их для помещения процесса в спящее состояние на заданный период времени:

sleep

и

alarm

не должны использоваться вместе. Сама

pause

создает состояние гонки; вместо этого нужно использовать блокирование сигналов и

sigsuspend

.

• Сигналы управления заданиями реализуют управление заданиями для оболочки. Большую часть времени следует оставлять их с установленными действиями по умолчанию, но полезно понимать, что иногда имеет смысл их перехватывать.

• Перехват

SIGCHLD

позволяет родителю узнать, что делает порожденный им процесс. Использование '

signal(SIGCHLD, SIG_IGN)

' (или

sigaction

с

SA_NOCLDWAIT

) вообще игнорирует потомков. Использование

sigaction

с

SA_NOCLDSTOP

предоставляет уведомления лишь о завершении. В последнем случае, независимо от того, заблокирован

SIGCHLD

или нет, обработчики сигналов для

SIGCHLD

должны быть готовы немедленно обработать несколько потомков. Наконец, использование

sigaction

без

SA_NOCLDSTOP

с обработчиком сигналов с тремя аргументами дает вам причину получения сигнала.

• После

fork

положение сигналов в порожденном процессе остается тем же самым, за исключением сброса ожидающих сигналов и установленных интервалов таймера. После

exec

положение несколько более сложно — в сущности, все, что может быть оставлено, остается; для всего остального восстанавливаются значения по умолчанию.

Упражнения

1. Реализуйте

bsd_signal

с использованием

sigaction

.

2. Если у вас не установлен GNU/Linux, запустите на своей системе

ch10-catchint

. Является ли ваша система традиционной или BSD?

3. Реализуйте функции System V Release 3

sighold

,

sigrelse

,

sigignore

,

sigpause

и

sigset

, использовав

sigaction

и другие подходящие функции из POSIX API.

4. Потренируйте свои навыки в жонглировании битами. В предположении, что сигнал 0 отсутствует и что имеется не более 31 сигналов, предусмотрите

typedef

для

sigset_t

и напишите

sigemptyset

,

sigfillset

,

sigaddset

,

sigdelset

и

sigismember

.

5. Еще немного потренируйте свои навыки жонглирования битами. Повторите предыдущее упражнение, на этот раз предположив, что наибольшим сигналом является 42.

6. Теперь, когда вы сделали предыдущие два упражнения, найдите

sigemptyset

и др. в своем заголовочном файле

<signal.h>

. (Может потребоваться поискать их; они могут быть в

#include

файлах, указанных в

<signal.h>

.) Являются ли они макросами или функциями?

7. В разделе 10.7 «Сигналы для межпроцессного взаимодействия» мы упомянули, что код изделия должен работать с начальной маской сигналов процесса, добавляя и удаляя блокируемые сигналы в вызове

sigsuspend

. Перепишите пример, используя для этого соответствующие вызовы.