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

выводили бы сообщение и продолжали работу; смысл сигнала в том, что они должны остановиться!

Например, рассмотрите программу

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

Установка действия

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

Значение

для (см. раздел 4.3 «Определение ошибок») указывает, что системный вызов был прерван. Хотя с этим значением ошибки может завершаться большое количество системных вызовов, двумя наиболее значительными являются и . Рассмотрите следующий код:

Предположим, что система успешно прочла (и заполнила) часть буфера, когда возник

. Системный вызов еще не вернулся из ядра в программу, но ядро решает, что оно может доставить сигнал. Вызывается , запускается и возвращается в середину . Что возвратит ?

В былые времена (V7, более ранние системы System V)

возвратила бы -1 и установила бы равным . Не было способа сообщить, что данные были переданы. В данном случае V7 и System V действуют, как если бы ничего не случилось: не было перемещений данных в и из буфера пользователя, и смещение файла не было изменено. BSD 4.2 изменила это. Были два случая:

Медленные устройства

«Медленное устройство» является в сущности терминалом или почти всяким другим устройством, кроме обычного файла. В этом случае

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

Обычные файлы

Системный вызов был бы запущен повторно В этом случае

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

Поведение BSD несомненно полезно; вы всегда можете сказать, сколько данных было прочитано.

Поведение POSIX сходно, но не идентично первоначальному поведению BSD. POSIX указывает, что

[108] завершается с ошибкой лишь в случае появления сигнала до начала перемещения данных. Хотя POSIX ничего не говорит о «медленных устройствах», на практике это условие проявляется именно на них.

В противном случае, если сигнал прерывает частично выполненную

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

Для обработки случая EINTR в традиционных системах GNU Coreutils использует две функции,

и . Код несколько запутан из-за того, что один и тот же файл за счет включения #include и макросов реализует обе функции. Из файла в дистрибутиве Coreutils: