Сигналы - это ограниченная форма межпроцессного взаимодействия (IPC), обычно используемая в Unix , Unix-подобных и других операционных системах, совместимых с POSIX . Сигнал - это асинхронное уведомление, отправляемое процессу или определенному потоку в том же процессе, чтобы уведомить его о событии. Сигналы возникли в 1970-х годах в Bell Labs Unix и позже были определены в стандарте POSIX .
Когда сигнал отправляется, операционная система прерывает нормальный поток выполнения целевого процесса, чтобы доставить сигнал. Выполнение может быть прервано любой неатомарной инструкцией . Если процесс ранее зарегистрировал обработчик сигнала , эта процедура выполняется. В противном случае выполняется обработчик сигнала по умолчанию.
Встроенные программы могут найти сигналы полезными для межпроцессного взаимодействия, поскольку сигналы отличаются своей алгоритмической эффективностью .
Сигналы похожи на прерывания , разница в том, что прерывания опосредуются процессором и обрабатываются ядром, в то время как сигналы опосредуются ядром (возможно, через системные вызовы) и обрабатываются процессами. Ядро может передать прерывание как сигнал процессу, который его вызвал (типичными примерами являются SIGSEGV , SIGBUS , SIGILL и SIGFPE ).
История
Версия 1 Unix имела отдельные системные вызовы для перехвата прерываний, завершений и машинных ловушек. Версия 4 объединила все ловушки в один вызов, сигнал , и каждая пронумерованная ловушка получила символическое имя в Версии 7 . kill появился в Версии 2 , а в Версии 5 мог посылать произвольные сигналы. [1] Plan 9 от Bell Labs заменил сигналы заметками , которые позволяют отправлять короткие произвольные строки. [ необходима цитата ]
Отправка сигналов
В Системный вызов kill (2) отправляет указанный сигнал указанному процессу, если позволяют разрешения. Точно так же Команда kill (1) позволяет пользователю отправлять сигналы процессам. В Функция библиотеки raise (3) отправляет указанный сигнал текущему процессу.
Такие исключения , как деление на ноль или нарушение сегментации, будут генерировать сигналы (здесь SIGFPE «исключение с плавающей запятой» и SIGSEGV «нарушение сегментации» соответственно, которые по умолчанию вызывают дамп ядра и выход из программы).
Ядро может генерировать сигналы для уведомления процессов о событиях. Например, SIGPIPE будет сгенерирован, когда процесс записывает в канал, который был закрыт читателем; по умолчанию это приводит к завершению процесса, что удобно при построении конвейеров оболочки .
Ввод определенных комбинаций клавиш на управляющем терминале запущенного процесса заставляет систему отправлять ему определенные сигналы: [2]
- Ctrl-C (в старых версиях Unix, DEL) отправляет сигнал INT («прерывание», SIGINT ); по умолчанию это приводит к завершению процесса.
- Ctrl-Z отправляет сигнал TSTP («конечная остановка», SIGTSTP ); по умолчанию это заставляет процесс приостанавливать выполнение. [3]
- Ctrl- \ отправляет сигнал QUIT ( SIGQUIT ); по умолчанию это приводит к завершению процесса и выгрузке ядра.
- Ctrl-T (поддерживается не во всех UNIX) отправляет сигнал INFO ( SIGINFO ); по умолчанию, и если это поддерживается командой, это заставляет операционную систему отображать информацию о запущенной команде. [4]
Эти комбинации клавиш по умолчанию в современных операционных системах можно изменить с помощью команда stty .
Обработка сигналов
Обработчики сигналов могут быть установлены с сигнал (2) или sigaction (2) системный вызов. Если обработчик сигнала не установлен для определенного сигнала, используется обработчик по умолчанию. В противном случае сигнал перехватывается и вызывается обработчик сигнала. Процесс также может указать два поведения по умолчанию без создания обработчика: игнорировать сигнал (SIG_IGN) и использовать обработчик сигнала по умолчанию (SIG_DFL). Есть два сигнала, которые нельзя перехватить и обработать: SIGKILL и SIGSTOP .
Риски
Обработка сигналов уязвима в условиях гонки . Поскольку сигналы являются асинхронными, другой сигнал (даже того же типа) может быть доставлен процессу во время выполнения процедуры обработки сигналов.
В Вызов sigprocmask (2) может использоваться для блокировки и разблокировки доставки сигналов. Заблокированные сигналы не доставляются в процесс, пока не будут разблокированы. Сигналы, которые нельзя игнорировать (SIGKILL и SIGSTOP), нельзя заблокировать.
Сигналы могут вызвать прерывание текущего системного вызова, оставляя приложение для управления непрозрачным перезапуском .
Обработчики сигналов должны быть написаны таким образом, чтобы не приводить к нежелательным побочным эффектам, например изменение ошибки, изменение маски сигнала, изменение расположения сигнала и другиеизменения атрибутовглобального процесса . Использование невозвратных функций, например, malloc или printf , внутренние обработчики сигналов также небезопасны. В частности, спецификация POSIX и справочная страница Linux signal (7) требует, чтобы все системные функции, прямо или косвенно вызываемые из сигнальной функции, были безопасными для асинхронных сигналов . [5] [6]На странице руководства signal-safety (7) приведен список таких безопасных системных функций async-signal (практически системные вызовы ), в противном случае это неопределенное поведение . [7] Предлагается просто установить некоторую volatile sig_atomic_t
переменную в обработчике сигнала и протестировать ее где-нибудь еще. [8]
Обработчики сигналов могут вместо этого поместить сигнал в очередь и немедленно вернуться. Затем основной поток будет продолжать "без прерывания" до тех пор, пока из очереди не будут взяты сигналы, например, в цикле событий . «Непрерывный» здесь означает, что операции, которые блокируют, могут вернуться преждевременно и должны быть возобновлены , как указано выше. Сигналы должны обрабатываться из очереди в основном потоке, а не рабочими пулами , поскольку это вновь вызывает проблему асинхронности. Однако управление очередью невозможно безопасным способом с асинхронным сигналом с помощью только sig_atomic_t , поскольку только одиночные операции чтения и записи в такие переменные гарантированно будут атомарными, а не приращениями или (выборкой-и) -декрементами, как это требуется для очереди. Таким образом, эффективно, только один сигнал для каждого обработчика может быть безопасно поставлен в очередь с помощью sig_atomic_t, пока он не будет обработан.
Связь с аппаратными исключениями
Выполнение процесса может привести к созданию аппаратного исключения , например, если процесс пытается разделить на ноль или вызывает ошибку страницы .
В Unix-подобных операционных системах это событие автоматически изменяет контекст процессора, чтобы начать выполнение обработчика исключений ядра . В случае некоторых исключений, таких как отказ страницы , ядро имеет достаточно информации, чтобы полностью обработать само событие и возобновить выполнение процесса.
Однако с другими исключениями ядро не может обрабатывать интеллектуально, и вместо этого оно должно отложить операцию обработки исключения процессу, вызвавшему сбой. Эта отсрочка достигается с помощью сигнального механизма, в котором ядро отправляет процессу сигнал, соответствующий текущему исключению. Например, если процесс предпринял попытку целочисленного деления на ноль на процессоре x86 , будет сгенерировано исключение ошибки разделения , и ядро отправит сигнал SIGFPE процессу.
Точно так же, если процесс пытается получить доступ к адресу памяти за пределами своего виртуального адресного пространства , ядро уведомит процесс об этом нарушении с помощью сигнала SIGSEGV . Точное соответствие между именами сигналов и исключениями, очевидно, зависит от ЦП, поскольку типы исключений различаются в зависимости от архитектуры.
Сигналы POSIX
В приведенном ниже списке представлены сигналы, указанные в спецификации Single Unix . Все сигналы определены как макроконстанты в
файле заголовка. Имя макроконстанты состоит из префикса «SIG», за которым следует мнемоническое имя сигнала.
- SIGABRT и SIGIOT
- Сигналы SIGABRT и SIGIOT отправляются процессу, чтобы сообщить ему об отмене , то есть о завершении. Сигнал обычно инициируется самим процессом, когда он вызывает abort()функцию стандартной библиотеки C , но он может быть отправлен процессу извне, как любой другой сигнал.
- СИГАЛРМ , SIGVTALRM и SIGPROF
- Сигналы SIGALRM, SIGVTALRM и SIGPROF отправляются процессу, когда истекает срок, указанный в вызове предыдущей функции установки сигнала тревоги (такой как
setitimer
). SIGALRM отправляется по истечении реального или часового времени. SIGVTALRM отправляется по истечении процессорного времени, используемого процессом. SIGPROF отправляется, когда время ЦП, используемое процессом и системой от имени процесса, истекает. - SIGBUS
- Сигнал SIGBUS отправляется процессу, когда он вызывает ошибку шины . Условия, которые приводят к отправке сигнала, - это, например, неправильное выравнивание доступа к памяти или несуществующий физический адрес.
- SIGCHLD
- Сигнал SIGCHLD отправляется процессу, когда дочерний процесс завершается , прерывается или возобновляется после прерывания. Одним из распространенных способов использования сигнала является указание операционной системе очистить ресурсы, используемые дочерним процессом после его завершения, без явного вызова
wait
системного вызова. - SIGCONT
- Сигнал SIGCONT предписывает операционной системе продолжить (перезапустить) процесс, ранее приостановленный сигналом SIGSTOP или SIGTSTP. Одно из важных применений этого сигнала - управление заданиями в оболочке Unix .
- SIGFPE
- Сигнал SIGFPE отправляется процессу, когда исключительное (но не обязательно ошибочное) условие было обнаружено в оборудовании для арифметических операций с плавающей запятой или целых чисел. Это может включать деление на ноль , переполнение или переполнение с плавающей запятой, целочисленное переполнение, недопустимую операцию или неточное вычисление. Поведение может отличаться в зависимости от оборудования.
- SIGHUP
- Сигнал SIGHUP отправляется процессу, когда его управляющий терминал закрыт. Первоначально он был разработан, чтобы уведомить процесс обрыва последовательной линии ( зависания ). В современных системах этот сигнал обычно означает, что управляющий псевдо или виртуальный терминал был закрыт. [9] Многие демоны (у которых нет управляющего терминала) интерпретируют получение этого сигнала как запрос на перезагрузку файлов конфигурации и очистку / повторное открытие файлов журнала вместо выхода. [10] nohup - это команда, заставляющая команду игнорировать сигнал.
- СИГИЛЛ
- Сигнал SIGILL отправляется процессу, когда он пытается выполнить недопустимую , некорректную, неизвестную или привилегированную инструкцию .
- SIGINT
- Сигнал SIGINT отправляется процессу его управляющим терминалом, когда пользователь желает прервать процесс. Обычно это запускается нажатием Ctrl+C , но в некоторых системах можно использовать символ « удалить » или « разрыв ». [11]
- СИГКИЛЛ
- Сигнал SIGKILL отправляется процессу, чтобы вызвать его немедленное завершение ( kill ). В отличие от SIGTERM и SIGINT, этот сигнал нельзя перехватить или проигнорировать, и принимающий процесс не может выполнить какую-либо очистку после получения этого сигнала. Применяются следующие исключения:
- Зомби-процессы нельзя убить, так как они уже мертвы и ждут, пока их родительские процессы не пожнут их.
- Процессы, находящиеся в заблокированном состоянии, не умрут, пока снова не проснутся.
- Процесс init особенный: он не получает сигналов, которые не хочет обрабатывать, и поэтому может игнорировать SIGKILL. [12] Исключением из этого правила является то, что в Linux выполняется трассировка init . [13] [14]
- Допускающим прерывания спит процесс не может прекратить (и освободить ресурсы) даже при отправке SIGKILL. Это один из немногих случаев, когда может потребоваться перезагрузка системы UNIX для решения временной проблемы программного обеспечения.
- SIGKILL используется в качестве последнего средства при завершении процессов в большинстве процедур завершения работы системы, если он не завершается добровольно в ответ на SIGTERM. Чтобы ускорить процедуру выключения компьютера, Mac OS X 10.6, также известная как Snow Leopard , будет отправлять сигнал SIGKILL приложениям, которые пометили себя как «чистые», что приводит к сокращению времени выключения без каких-либо побочных эффектов. [15] Команда
killall -9
имеет похожий, хотя и опасный эффект, когда выполняется, например, в Linux; он не позволяет программам сохранять несохраненные данные. У него есть другие варианты, и без них используется более безопасный сигнал SIGTERM. - SIGPIPE
- Сигнал SIGPIPE отправляется процессу, когда он пытается записать в канал без подключения процесса к другому концу.
- SIGPOLL
- Сигнал SIGPOLL отправляется, когда событие происходит в явно наблюдаемом файловом дескрипторе. [16] Его использование эффективно приводит к выполнению запросов асинхронного ввода-вывода, поскольку ядро опрашивает дескриптор вместо вызывающего. Это альтернатива активному опросу .
- SIGRTMIN на SIGRTMAX
- Сигналы от SIGRTMIN к SIGRTMAX предназначены для использования в определенных пользователем целях. Это сигналы в реальном времени .
- SIGQUIT
- Сигнал SIGQUIT посылается в процесс его управляющий терминалом , когда пользователь запрашивает , что процесс выхода и выполнить дамп .
- SIGSEGV
- SIGSEGV посылается сигнал процессу , когда он делает недопустимую ссылку виртуальной памяти, или сегментацию ошибки , то есть , когда он выполняет SEG мыслительности v iolation . [17]
- SIGSTOP
- Сигнал SIGSTOP предписывает операционной системе остановить процесс для последующего возобновления.
- SIGSYS
- Сигнал SIGSYS отправляется процессу, когда он передает неверный аргумент системному вызову . На практике этот вид сигналов встречается редко, поскольку приложения полагаются на библиотеки (например, libc ), чтобы выполнять их вызов. SIGSYS может быть получен приложениями, нарушающими правила безопасности Linux Seccomp, настроенные для их ограничения. SIGSYS также можно использовать для имитации внешних системных вызовов, например, для эмуляции системных вызовов Windows в Linux. [18]
- SIGTERM
- Сигнал SIGTERM отправляется процессу для запроса его завершения . В отличие от сигнала SIGKILL, он может быть перехвачен и интерпретирован или проигнорирован процессом. Это позволяет процессу выполнять корректное завершение, высвобождая ресурсы и сохраняя состояние, если необходимо. SIGINT почти идентичен SIGTERM.
- SIGTSTP
- SIGTSTP сигнал посылается к процессу с помощью контролирующего терминала , чтобы запросить его остановки ( т erminal й о р ). Обычно он запускается нажатием кнопки Ctrl+Z . В отличие от SIGSTOP, процесс может зарегистрировать обработчик сигнала или игнорировать сигнал.
- SIGTTIN и SIGTTOU
- В SIGTTIN и SIGTTOU сигналы передаются к процессу , когда он пытается прочитать в или записи из соответственно от TTY в то время как в фоновом режиме . Обычно эти сигналы получают только процессы, находящиеся под управлением заданий ; демоны не имеют управляющих терминалов и, следовательно, никогда не должны получать эти сигналы.
- SIGTRAP
- Сигнал SIGTRAP отправляется процессу, когда возникает исключение (или ловушка ): условие, о котором отладчик запросил информировать - например, когда выполняется определенная функция или когда конкретная переменная меняет значение.
- СИГУРГ
- Сигнал SIGURG отправляется процессу, когда сокет имеет срочные или внеполосные данные, доступные для чтения.
- SIGUSR1 и SIGUSR2
- Сигналы SIGUSR1 и SIGUSR2 отправляются процессу для обозначения условий, определенных пользователем .
- SIGXCPU
- Сигнал SIGXCPU отправляется процессу, когда он израсходовал CPU в течение времени, превышающего определенное заранее заданное пользователем значение. [19] Прибытие сигнала SIGXCPU дает принимающему процессу возможность быстро сохранить любые промежуточные результаты и корректно завершить работу до того, как операционная система завершит его с помощью сигнала SIGKILL.
- SIGXFSZ
- Сигнал SIGXFSZ отправляется процессу, когда он увеличивает размер файла , превышающего максимально допустимый размер .
- SIGWINCH
- Сигнал SIGWINCH посылается процессу , когда терминал управления изменяет свой размер (а выигрыш Дау ч АНЖ). [20]
Действие по умолчанию
Процесс может определять, как обрабатывать входящие сигналы POSIX . Если процесс не определяет поведение для сигнала, то используется обработчик по умолчанию для этого сигнала. В таблице ниже перечислены некоторые действия по умолчанию для POSIX-совместимых систем UNIX, таких как FreeBSD , OpenBSD и Linux .
Сигнал | Портативный номер | Действие по умолчанию | Описание |
---|---|---|---|
SIGABRT | 6 | Завершить (дамп ядра) | Сигнал прерывания процесса |
SIGALRM | 14 | Прекратить | Будильник |
SIGBUS | N / A | Завершить (дамп ядра) | Доступ к неопределенной части объекта памяти |
SIGCHLD | N / A | Игнорировать | Дочерний процесс завершен, остановлен или продолжен |
SIGCONT | N / A | Продолжать | Продолжить выполнение, если остановлено |
SIGFPE | 8 | Завершить (дамп ядра) | Ошибочные арифметические операции |
SIGHUP | 1 | Прекратить | Вешать трубку |
СИГИЛЛ | 4 | Завершить (дамп ядра) | Незаконная инструкция |
SIGINT | 2 | Прекратить | Сигнал прерывания клеммы |
СИГКИЛЛ | 9 | Прекратить | Убить (нельзя поймать или проигнорировать) |
SIGPIPE | 13 | Прекратить | Пишите на трубе, и некому читать. |
SIGPOLL | N / A | Прекратить | Опрашиваемое событие |
SIGPROF | N / A | Прекратить | Таймер профилирования истек |
SIGQUIT | 3 | Завершить (дамп ядра) | Сигнал выхода из терминала |
SIGSEGV | 11 | Завершить (дамп ядра) | Неверная ссылка на память |
SIGSTOP | N / A | Стоп | Прекратить выполнение (не может быть поймано или проигнорировано) |
SIGSYS | N / A | Завершить (дамп ядра) | Плохой системный вызов |
SIGTERM | 15 | Прекратить | Сигнал завершения |
SIGTRAP | 5 | Завершить (дамп ядра) | Ловушка трассировки / точки останова |
SIGTSTP | N / A | Стоп | Сигнал остановки терминала |
SIGTTIN | N / A | Стоп | Фоновый процесс пытается прочитать |
SIGTTOU | N / A | Стоп | Фоновый процесс пытается записать |
SIGUSR1 | N / A | Прекратить | Определяемый пользователем сигнал 1 |
SIGUSR2 | N / A | Прекратить | Определяемый пользователем сигнал 2 |
СИГУРГ | N / A | Игнорировать | Внеполосные данные доступны через сокет |
SIGVTALRM | N / A | Прекратить | Срок действия виртуального таймера истек |
SIGXCPU | N / A | Завершить (дамп ядра) | Превышен лимит времени ЦП |
SIGXFSZ | N / A | Завершить (дамп ядра) | Превышен предел размера файла |
SIGWINCH | N / A | Игнорировать | Размер окна терминала изменен |
- Портативный номер:
- Для большинства сигналов соответствующий номер сигнала определяется реализацией. В этом столбце перечислены числа, указанные в стандарте POSIX. [21]
- Объяснение действий:
- Завершить - аварийное завершение процесса. Процесс завершается со всеми последствиями _exit (), за исключением того, что статус, доступный для wait () и waitpid (), указывает на аварийное завершение по указанному сигналу.
- Завершить (дамп ядра) - аварийное завершение процесса. Кроме того, могут возникать определенные реализацией аномальные действия завершения, такие как создание основного файла.
- Игнорировать - игнорировать сигнал.
- Остановить - остановить (не завершить) процесс.
- Продолжить - продолжить процесс, если он остановлен; в противном случае игнорируйте сигнал.
Разные сигналы
Следующие сигналы не указаны в спецификации POSIX . Однако они иногда используются в различных системах.
- SIGEMT
- Сигнал SIGEMT отправляется процессу при возникновении ловушки эмулятора .
- СИГИНФО
- Сигнал SIGINFO отправляется процессу при получении запроса статуса ( информации ) от управляющего терминала.
- SIGPWR
- Сигнал SIGPWR отправляется процессу, когда в системе происходит сбой питания .
- СИГЛОСТ
- Сигнал SIGLOST отправляется процессу при потере блокировки файла .
- SIGSTKFLT
- Сигнал SIGSTKFLT посылается процесс , когда сопроцессор испытывает й ас к й аи л (т.е. появляется , когда стек пуст или толкающий , когда она полна). [22] Он определен, но не используется в Linux, где ошибка стека сопроцессора x87 вместо этого генерирует SIGFPE. [23]
- SIGUNUSED
- Сигнал SIGUNUSED отправляется процессу при выполнении системного вызова с неиспользуемым номером системного вызова. Это синоним SIGSYS на большинстве архитектур. [22]
- SIGCLD
- Сигнал SIGCLD является синонимом SIGCHLD. [22]
Смотрите также
- Обработка сигналов C
Рекомендации
- Перейти ↑ McIlroy, MD (1987). Читатель Research Unix: аннотированные выдержки из Руководства программиста, 1971–1986 (PDF) (технический отчет). CSTR. Bell Labs. 139.
- ^ «Сигналы завершения» . Библиотека GNU C) .
- ^ «Сигналы управления заданиями» . GNU C Library .
- ^ «Разные сигналы» . GNU C Library .
- ^ «Базовые спецификации Open Group, выпуск 6, IEEE Std 1003.1, издание 2004 г .: Системные интерфейсы, глава 2» . pubs.opengroup.org . Проверено 20 декабря 2020 .
- ^ "signal (7) - страница руководства Linux" . man7.org . Проверено 20 декабря 2020 .
- ^ "signal-security (7) - страница руководства Linux" . man7.org . Проверено 20 декабря 2020 .
- ^ «Базовые спецификации Open Group, выпуск 6, IEEE Std 1003.1, издание 2004 г .: » . pubs.opengroup.org . Проверено 20 декабря 2020 .
- ^ Майкл Керриск (25 июля 2009 г.). "сигнал (7)" . Руководство программиста Linux (версия 3.22) . Архивы ядра Linux . Проверено 23 сентября 2009 года .
- ^ "perlipc (1)" . Справочное руководство программистов Perl, версия 5.18 . perldoc.perl.org - Официальная документация по языку программирования Perl . Проверено 21 сентября 2013 года .
- ^ «Правильное обращение с SIGINT и SIGQUIT» . Проверено 6 октября 2012 года .
- ^ https://manpages.ubuntu.com/manpages/zesty/man2/kill.2.html раздел ПРИМЕЧАНИЯ
- ^ "Процесс инициализации SIGKILL (PID 1)" . Переполнение стека .
- ^ "Может ли root убить процесс инициализации?" . Обмен стеков Unix и Linux .
- ^ «Центр разработки для Mac: что нового в Mac OS X: Mac OS X v10.6» . 28 августа 2009 . Проверено 18 ноября 2017 года .
- ^ «ioctl - управляет СТРИМ-устройством» . Спецификация системного вызова POSIX . Открытая группа . Дата обращения 19 июня 2015 .
- ^ "Что такое" нарушение сегментации "?" . support.microfocus.com . Проверено 22 ноября 2018 .
- ^ «Syscall User Dispatch - Документация ядра Linux» . kernel.org . Проверено 11 февраля 2021 года .
- ^ «getrlimit, setrlimit - контролировать максимальное потребление ресурсов» . Спецификация системного вызова POSIX . Открытая группа . Проверено 10 сентября 2009 года .
- ^ Клаузекер, Роберт (19 июня 2017 г.). «0001151: Представьте новый сигнал SIGWINCH и функции tcsetsize (), tcgetsize () для получения / установки размера окна терминала» . Система отслеживания дефектов Austin Group . Остин Групп . Проверено 12 октября 2017 года .
Принято как отмеченное
- ^ «IEEE Std 1003.1-2017 - убить» . IEEE, открытая группа.
Соответствие между целочисленными значениями и используемым значением sig показано в следующем списке. Эффекты указания любого signal_number, кроме перечисленных ниже, не определены.
- ^ а б в "signal (7) - справочные страницы Linux" . manpages.courier-mta.org . Проверено 22 ноября 2018 .
- ^ «Linux 3.0 x86_64: когда поднимается SIGSTKFLT?» . Переполнение стека .
- Стивенс, В. Ричард (1992). Расширенное программирование в среде UNIX® . Ридинг, Массачусетс: Эддисон Уэсли. ISBN 0-201-56317-7.
- «Базовые спецификации Open Group, выпуск 7, издание 2013 г.» . Открытая группа . Дата обращения 19 июня 2015 .
Внешние ссылки
- Таблица сигналов Unix, Али Аланджави, Питтсбургский университет
- Man7.org Signal Man Страница
- Введение в программирование сигналов Unix Введение в программирование сигналов Unix на Wayback Machine (архивировано 26 сентября 2013 г.)
- Еще одно введение в программирование сигналов Unix (сообщение в блоге, 2009 г.)
- UNIX и надежные сигналы POSIX , Барис Симсек
- Обработчики сигналов Хеннинга Брауэра