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

, или , он не может вызвать . описана в разделе 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

.)

• То, что случается при прерывании сигналом системного вызова, также различается в традиционной и BSD линейках. Традиционные системы возвращают -1 с errno, установленным в

. BSD системы повторно запускают системный вызов после возвращения из обработчика. Макрос GLIBC может помочь вам написать код для обработки системных вызовов, возвращающих -1 с , установленным в .

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

• Механизм

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

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

Несмотря на эти проблемы интерфейса

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

BSD 4.0 (примерно с 1980 г.) ввел дополнительные функции API для предоставления «надежных» сигналов. [109] В частности, стало возможным блокировать сигналы. Другими словами, программа могла сообщить ядру: «Зависни на этих конкретных сигналах в течении следующего небольшого промежутка времени, затем доставь их мне, когда я буду готов их принять». Большим преимуществом является то, что эта особенность упрощает обработчики сигналов, которые автоматически запускаются со своим заблокированным сигналом (чтобы избежать проблемы одновременной обработки двух сигналов) и, возможно, также и с другими заблокированными сигналами.

System V Release 3 (примерно с 1984 г.) приняла эти API и популяризовала их, в большинстве связанных с Unix документации и книгах вы, возможно, увидите, что на эти API ссылаются, как ведущие начало от System V Release 3. Эти функции следующие: