Чтение онлайн

Пока обработка одного сигнала за раз выглядит просто: установка обработчика сигнала в

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

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

Или предположим, что вы используете

, так что обработчик остается установленным, но второй сигнал отличается от первого? Обычно обработчику первого сигнала нужно завершить свою работу до того, как запускается второй, а каждый обработчик сигнала не должен временно игнорировать все прочие возможные сигналы!

Оба случая относятся к состоянию гонки. Одним решением для этих проблем является как можно большее упрощение обработчиков сигналов. Это можно сделать, создав флаговые переменные, указывающие на появление сигнала. Обработчик сигнала устанавливает переменную в true и возвращается. Затем основная логика проверяет флаговую переменную в стратегических местах:

(Обратите внимание, что эта стратегия уменьшает окно уязвимости, но не устраняет его).

Стандарт С вводит специальный тип —

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

Наличие особого типа является лишь частью истории. Переменные

должны быть также объявлены как :

Ключевое слово

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

Структурирование приложения исключительно вокруг переменных

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

Стандарт POSIX предусматривает для обработчиков сигналов несколько предостережений:

• Что случается, когда возвращаются обработчики для

, , или любых других сигналов, представляющих «вычислительные исключения», не определено.

• Если обработчик был вызван в результате вызова

, или , он не может вызвать . описана в разделе 12.4 «Совершение самоубийства: », a описана далее в этой главе. (Описанная далее функция API с обработчиком сигнала, принимающая три аргумента, дает возможность сообщить об этом, если это имеет место.)

• Обработчики сигналов могут вызвать лишь функции из табл. 10.2. В частности, они должны избегать функций

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

Список в табл. 10.2 происходит из раздела 2.4 тома System Interfaces (Системные интерфейсы) стандарта POSIX 2001. Многие из этих функций относятся к сложному API и больше не рассматриваются в данной книге.

Таблица 10.2. Функции, которые могут быть вызваны из обработчика сигнала

_Exit	fpathconf	raise	sigqueue
_exit	fstat	read	sigset
accept	fsync	readlink	sigsuspend
access	ftruncate	recv	sleep
aio_error	getegid	recvfrom	socket
aio_return	geteuid	recvmsg	socketpair
aio_suspend	getgid	rename	stat
alarm	getgroups	rmdir	sysmlink
bind	getpeername	select	sysconf
cfgetispeed	getpgrp	sem_post	tcdrain
cfgetospeed	getpid	send	tcflow
cfsetispeed	getppid	sendmsg	tcflush
cfsetospeed	getsockname	sendto	tcgetattr
chdir	getsockopt	setgid	tcgetpgrp
chmod	getuid	setpgid	tcsendbreak
chown	kill	setsid	tcsetattr
clock_gettime	link	setsockopt	tcsetpgrp
close	listen	setuid	time
connect	lseek	shutdown	timer_getoverrun
creat	lstat	sigaction	timer_gettime
dup	mkdir	sigaddset	timer_settime
dup2	mkfifo	sigdelset	times
execle	open	sigemptyset	umask
execve	pathconf	sigfillset	uname
fchmod	pause	sigismember	unlink
fchown	pipe	signal	utime
fcntl	poll	sigpause	wait
fdatasync	posix_trace_event	sigpending	waitpid
fork	pselect	sigprocmask	write

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

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

• 

является функцией ISO С для отправки сигнала текущему процессу. Как отправлять сигналы другим процессам, нам еще предстоит описать.

• 

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

• Когда сигнал перехватывается, вызывается функция-обработчик. Вот где сложность начинает поднимать свою безобразную голову:

 • ISO С не определяет, восстанавливается ли диспозиция сигнала по умолчанию до вызова обработчика или она остается на месте. Первое является поведением V7 и современных систем System V, таких, как Solaris. Последнее является поведением BSD, используемым также в GNU/Linux. (Для форсирования поведения BSD может использоваться функция POSIX

.)