Сигнал (МПК)
Эта статья нуждается в дополнительных цитатах для проверки . ( август 2012 г. ) |
Сигналы — это стандартизированные сообщения, отправляемые работающей программе для запуска определенного поведения, например выхода из программы или обработки ошибок. Они представляют собой ограниченную форму межпроцессного взаимодействия (IPC), обычно используемую в Unix , Unix-подобных и других POSIX -совместимых операционных системах.
Сигнал — это асинхронное уведомление, отправляемое процессу или определенному потоку внутри того же процесса для уведомления о событии. Обычно сигналы используются для прерывания, приостановки, завершения или завершения процесса. Сигналы возникли в Bell Labs Unix 1970-х годов и позже были определены в стандарте POSIX .
Когда сигнал отправляется, операционная система прерывает нормальный ход выполнения целевого процесса, чтобы доставить сигнал. Выполнение может быть прервано во время выполнения любой неатомарной инструкции . Если процесс ранее зарегистрировал обработчик сигнала , эта процедура выполняется. В противном случае выполняется обработчик сигнала по умолчанию.
Встроенные программы могут найти сигналы полезными для межпроцессного взаимодействия, поскольку сигналы отличаются своей алгоритмической эффективностью .
Сигналы аналогичны прерываниям , разница в том, что прерывания опосредуются ЦП и обрабатываются ядром , тогда как сигналы опосредуются ядром (возможно, посредством системных вызовов) и обрабатываются отдельными процессами . [ нужна ссылка ] Ядро может передать прерывание в качестве сигнала процессу, который его вызвал (типичные примеры — SIGSEGV , SIGBUS , SIGILL и SIGFPE ).
История
[ редактировать ]- Версия 1 Unix (1971 г.) имела отдельные системные вызовы для перехвата прерываний, выходов и машинных ловушек.
- kill появился во второй версии (1972).
- Версия 4 (1973 г.) объединила все ловушки в один вызов, сигнал .
- Версия 5 (1974 г.) могла отправлять произвольные сигналы. [1]
- В версии 7 (1979 г.) каждая пронумерованная ловушка получила символическое имя.
- Plan 9 от Bell Labs (конец 80-х) заменил сигналы заметками , которые позволяют отправлять короткие произвольные строки. [2]
Отправка сигналов
[ редактировать ]The Системный вызов kill (2) отправляет указанный сигнал указанному процессу, если разрешения позволяют. Аналогичным образом, Команда kill(1) позволяет пользователю отправлять сигналы процессам. Библиотечная функция raise(3) отправляет указанный сигнал текущему процессу.
Такие исключения , как деление на ноль , нарушение сегментации ( SIGSEGV ) и исключение с плавающей запятой ( SIGFPE ), вызовут дамп ядра и завершат работу программы.
Ядро может генерировать сигналы для уведомления процессов о событиях. Например, SIGPIPE будет генерироваться, когда процесс записывает данные в канал, который был закрыт считывателем; по умолчанию это приводит к завершению процесса, что удобно при построении конвейеров оболочки .
Ввод определенных комбинаций клавиш на управляющем терминале запущенного процесса заставляет систему отправлять ему определенные сигналы: [3]
- Ctrl-C (в старых Unix-системах DEL) отправляет сигнал INT («прерывание», SIGINT ); по умолчанию это приводит к завершению процесса.
- Ctrl-Z отправляет сигнал TSTP («остановка терминала», SIGTSTP ); по умолчанию это приводит к приостановке выполнения процесса. [4]
- Ctrl-\ отправляет сигнал ВЫХОДА ( SIGQUIT ); по умолчанию это приводит к завершению процесса и сбросу ядра.
- Ctrl-T (поддерживается не во всех UNIX) отправляет сигнал INFO ( SIGINFO ); по умолчанию, и если это поддерживается командой, это заставляет операционную систему отображать информацию о выполняемой команде. [5]
Эти комбинации клавиш по умолчанию в современных операционных системах можно изменить с помощью команда stty .
Обработка сигналов
[ редактировать ]Обработчики сигналов могут быть установлены с помощью сигнал(2) или sigaction(2) Системный вызов . Если для конкретного сигнала не установлен обработчик, используется обработчик по умолчанию. В противном случае сигнал перехватывается и вызывается обработчик сигнала. Процесс также может указать два варианта поведения по умолчанию без создания обработчика: игнорировать сигнал (SIG_IGN) и использовать обработчик сигнала по умолчанию (SIG_DFL). Есть два сигнала, которые невозможно перехватить и обработать: SIGKILL и SIGSTOP .
Риски
[ редактировать ]Обработка сигналов уязвима к условиям гонки . Поскольку сигналы асинхронны, другой сигнал (даже того же типа) может быть доставлен процессу во время выполнения процедуры обработки сигнала.
The Вызов sigprocmask(2) можно использовать для блокировки и разблокировки доставки сигналов. Заблокированные сигналы не доставляются в процесс до тех пор, пока не будут разблокированы. Сигналы, которые нельзя игнорировать (SIGKILL и SIGSTOP), нельзя заблокировать.
Сигналы могут привести к прерыванию текущего системного вызова, оставляя приложению возможность управлять непрозрачным перезапуском .
Обработчики сигналов должны быть написаны таким образом, чтобы не вызывать нежелательных побочных эффектов, например изменение ошибок , изменение маски сигнала, изменение расположения сигнала и другие глобальные процесса изменения атрибутов . Использование нереентерабельных функций , например, malloc или printf , внутренние обработчики сигналов также небезопасны. В частности, спецификация POSIX и справочная страница Linux. signal (7) требует, чтобы все системные функции, прямо или косвенно вызываемые из функции signal, были безопасными для асинхронных сигналов . [6] [7] На странице руководства signal-safety(7) приведен список таких безопасных системных функций с асинхронным сигналом (практически системные вызовы ), в противном случае это неопределенное поведение . [8] Предлагается просто установить некоторые volatile sig_atomic_t
переменную в обработчике сигнала и протестировать ее в другом месте. [9]
Вместо этого обработчики сигналов могут поместить сигнал в очередь и немедленно вернуться. Затем основной поток будет продолжать работать «непрерывно», пока сигналы не будут взяты из очереди, например, в цикле событий . операции «Непрерывный» здесь означает, что блокирующие могут вернуться преждевременно и их необходимо возобновить , как упоминалось выше. Сигналы должны обрабатываться из очереди в основном потоке, а не в рабочих пулах , поскольку это вновь порождает проблему асинхронности. Однако управление очередью невозможно безопасным для асинхронного сигнала способом, используя только sig_atomic_t , поскольку только одиночные операции чтения и записи в такие переменные гарантированно будут атомарными, а не инкрементами или (выборками и) декрементами, как это требуется для очереди. Таким образом, фактически только один сигнал на каждый обработчик может быть безопасно поставлен в очередь с помощью sig_atomic_t , пока он не будет обработан.
Связь с аппаратными исключениями
[ редактировать ]Выполнение процесса страничная может привести к генерации аппаратного исключения , например, если процесс пытается разделить на ноль или возникает ошибка .
В Unix-подобных процессора операционных системах это событие автоматически изменяет контекст , чтобы начать выполнение ядра обработчика исключений . В случае некоторых исключений, таких как ошибка страницы , ядро располагает достаточной информацией, чтобы полностью обработать само событие и возобновить выполнение процесса.
Однако другие исключения ядро не может обработать разумно и вместо этого должно отложить операцию обработки исключения процессу, вызвавшему ошибку. Эта отсрочка достигается с помощью механизма сигналов, при котором ядро отправляет процессу сигнал, соответствующий текущему исключению. Например, если процесс попытается выполнить целочисленное деление на ноль на x86 процессоре , будет сгенерировано исключение ошибки деления , в результате чего ядро отправит SIGFPE процессу сигнал .
Аналогично, если процесс попытается получить доступ к адресу памяти за пределами своего виртуального адресного пространства , ядро уведомит процесс об этом нарушении через SIGSEGV ( сигнал нарушения сегментации ). Точное сопоставление имен сигналов и исключений, очевидно, зависит от процессора, поскольку типы исключений различаются в зависимости от архитектуры.
Сигналы POSIX
[ редактировать ]В приведенном ниже списке документированы сигналы, указанные в Единой спецификации Unix . Все сигналы определяются как макроконстанты в <signal.h>
заголовочный файл. Имя макроконстанты состоит из префикса «SIG», за которым следует мнемоническое имя сигнала.
- СИГАБРТ и СИГИОТ
- «Прерывание сигнала», «ловушка ввода/вывода сигнала»
- Сигнал SIGABRT отправляется процессу, чтобы сообщить ему о прекращении , то есть о завершении. Сигнал обычно инициируется самим процессом, когда он вызывает
abort()
функция стандартной библиотеки C , но его можно отправить процессу извне, как и любой другой сигнал. - SIGIOT указывает, что ЦП выполнил явную инструкцию «ловушки» (без определенной функции) или нереализованную инструкцию (когда эмуляция недоступна).
- Примечание: «ловушка ввода/вывода» — неправильное название любой «ловушки» инструкции ЦП. Этот термин отражает раннее использование таких инструкций, преимущественно для реализации функций ввода-вывода, но они по своей сути не связаны с вводом-выводом устройства и могут использоваться для других целей, таких как связь между виртуальными и реальными хостами.
- SIGIOT и SIGABRT обычно представляют собой один и тот же сигнал, и получение этого сигнала может указывать на любое из вышеперечисленных условий.
- СИГАЛРМ , СИГВТАЛРМ и СИГПРОФ
- «Тревога сигнала», «Тревога виртуального таймера сигнала», «Тревога таймера профилирования сигнала»
- Сигналы SIGALRM, SIGVTALRM и SIGPROF отправляются процессу, когда достигается соответствующий предел времени. Процесс устанавливает эти временные ограничения, вызывая
alarm
илиsetitimer
. Ограничение времени для SIGALRM основано на реальном времени или времени по часам; SIGVTALRM основан на времени процессора, используемом процессом; а SIGPROF основан на времени ЦП, используемом процессом и системой от его имени (так называемый таймер профилирования ). В некоторых системах SIGALRM может использоваться внутри компании путем реализацииsleep
функция. - СИГБУС
- «Сигнальная шина»
- Сигнал SIGBUS отправляется процессу, когда он вызывает ошибку шины . Условиями, которые приводят к отправке сигнала, являются, например, неправильное выравнивание доступа к памяти или несуществующий физический адрес.
- СИГЧЛД
- «Сигнальный ребенок»
- Сигнал SIGCHLD отправляется процессу, когда дочерний процесс завершается , останавливается или возобновляется после остановки. Одним из распространенных вариантов использования сигнала является указание операционной системе очистить ресурсы, используемые дочерним процессом, после его завершения, без явного вызова метода.
wait
системный вызов. - СИГКОНТ
- «Сигнал продолжения»
- Сигнал SIGCONT дает указание операционной системе продолжить (перезапустить) процесс, ранее приостановленный сигналом SIGSTOP или SIGTSTP. Одним из важных применений этого сигнала является управление заданиями в оболочке Unix .
- SIGFPE
- «Сигнал ошибки с плавающей запятой »
- Сигнал SIGFPE отправляется процессу, когда в аппаратном обеспечении операций с плавающей запятой или целочисленной арифметики обнаружено исключительное (но не обязательно ошибочное) состояние. Это может включать деление на ноль , опустошение или переполнение с плавающей запятой, переполнение целого числа , недопустимую операцию или неточное вычисление. Поведение может отличаться в зависимости от оборудования.
- ПОДПИСАТЬСЯ
- «Сигнал повесить трубку».
- Сигнал SIGHUP отправляется процессу, когда его управляющий терминал закрыт. Первоначально он был разработан для уведомления процесса обрыва последовательной линии ( зависания ). В современных системах этот сигнал обычно означает, что управляющий псевдо- или виртуальный терминал закрыт. [10] Многие демоны (у которых нет управляющего терминала) интерпретируют получение этого сигнала как запрос на перезагрузку файлов конфигурации и очистку/повторное открытие файлов журналов вместо выхода. [11] nohup — это команда, позволяющая команде игнорировать сигнал.
- ТЮЛЕНЬ
- «Сигнал незаконен»
- Сигнал SIGILL отправляется процессу, когда он пытается выполнить недопустимую , неверную, неизвестную или привилегированную инструкцию .
- СИГНАЛ
- «Прерывание сигнала»
- Сигнал SIGINT отправляется процессу управляющим терминалом, когда пользователь желает прервать процесс. Обычно это инициируется нажатием Ctrl+ C, но в некоторых системах « delete » или « break ». можно использовать клавишу [12]
- СИГКИЛЛ
- «Сигнал убить»
- Сигнал SIGKILL отправляется процессу, чтобы заставить его немедленно завершиться ( kill ). В отличие от SIGTERM и SIGINT, этот сигнал нельзя перехватить или проигнорировать, и принимающий процесс не может выполнить какую-либо очистку после получения этого сигнала. Применяются следующие исключения:
- Процессы-зомби не могут быть уничтожены, поскольку они уже мертвы и ждут, пока родительские процессы их пожнут.
- Процессы, находящиеся в заблокированном состоянии, не умрут, пока не пробудятся снова.
- Процесс инициализации уникален: он не получает сигналов, которые не хочет обрабатывать, и поэтому может игнорировать SIGKILL. [13] Исключением из этого правила является использование init в Linux. [14] [15]
- Непрерывно спящий процесс не может завершиться (и освободить свои ресурсы) даже при отправке SIGKILL. Это один из немногих случаев, когда для решения временной проблемы с программным обеспечением может потребоваться перезагрузка системы UNIX.
- SIGKILL используется в качестве крайней меры при завершении процессов в большинстве процедур завершения работы системы , если он не завершается добровольно в ответ на SIGTERM. Чтобы ускорить процедуру выключения компьютера, Mac OS X 10.6, также известная как Snow Leopard , отправляет SIGKILL приложениям, которые пометили себя как «чистые», что приводит к более быстрому завершению работы без каких-либо побочных эффектов. [16] Команда
killall -9
имеет аналогичный, хотя и опасный эффект, при выполнении, например, в Linux; он не позволяет программам сохранять несохраненные данные. У него есть другие варианты, и при их отсутствии используется более безопасный сигнал SIGTERM. - СИГПАЙП
- «Сигнальная труба»
- Сигнал SIGPIPE отправляется процессу, когда он пытается выполнить запись в канал без подключения процесса к другому концу.
- СИГ ОПРОС
- «Сигнальный опрос»
- Сигнал SIGPOLL отправляется, когда происходит событие в явно отслеживаемом файловом дескрипторе. [17] Его эффективное использование приводит к выполнению асинхронных запросов ввода-вывода , поскольку ядро будет опрашивать дескриптор вместо вызывающего объекта. Он обеспечивает альтернативу активному опросу .
- СИГРТМИН для СИГРТМАКС
- «Минимум сигнала в реальном времени», «Максимум сигнала в реальном времени»
- Сигналы от SIGRTMIN до SIGRTMAX предназначены для использования в целях, определяемых пользователем. Это сигналы реального времени .
- СИГНАЛИЗАЦИЯ
- «Сигнал выхода»
- Сигнал SIGQUIT отправляется процессу управляющим терминалом, когда пользователь запрашивает завершение процесса и выполнение дампа ядра .
- СИГСЕГВ
- «Нарушение сегментации сигнала»
- Сигнал SIGSEGV отправляется процессу, когда он делает недопустимую ссылку на виртуальную память или сегментации , т. е. когда он выполняет сегментации нарушение ошибку . [18]
- СИГСТОП
- «Сигнал стоп»
- Сигнал SIGSTOP инструктирует операционную систему остановить процесс для последующего возобновления.
- СИГСИС
- «Сигнальный системный вызов»
- Сигнал SIGSYS отправляется процессу, когда он передает неверный аргумент системному вызову . На практике этот тип сигнала встречается редко, поскольку приложения используют библиотеки (например, libc ) для их вызова. SIGSYS могут получить приложения, нарушающие правила безопасности Linux Seccomp, настроенные для их ограничения. SIGSYS также можно использовать для эмуляции внешних системных вызовов, например, для эмуляции системных вызовов Windows в Linux. [19]
- ЦЕЛЕВОЙ СРОК
- «Прекращение сигнала»
- Сигнал SIGTERM отправляется процессу для запроса его завершения . В отличие от сигнала SIGKILL, он может быть перехвачен и интерпретирован или проигнорирован процессом. Это позволяет процессу выполнить корректное завершение, освобождая ресурсы и сохраняя состояние, если это необходимо. SIGINT практически идентичен SIGTERM.
- СИГТСТП
- «Сигнальный терминал остановки»
- Сигнал SIGTSTP посылается процессу управляющим терминалом чтобы запросить остановку ( остановка терминала ) , его . Обычно он инициируется нажатием пользователем Ctrl+ Z. В отличие от SIGSTOP, процесс может зарегистрировать обработчик сигнала или игнорировать его.
- СИГТТИН и СИГТТУ
- Сигналы SIGTTIN и SIGTTOU передаются процессу, когда он пытается прочитать или записать данные соответственно, из терминала находясь в фоновом режиме . Обычно эти сигналы принимаются только процессами, находящимися под управлением задания ; демоны не имеют управляющих терминалов и, следовательно, никогда не должны получать эти сигналы.
- СИГНАЛЬНАЯ ЛОВУШКА
- «Сигнальная ловушка»
- Сигнал SIGTRAP отправляется процессу при возникновении исключения (или ловушки ): условия, о котором отладчик запросил информацию — например, когда определенная функция выполняется или когда определенная переменная меняет значение.
- ПОБЕДА
- «Сигнал срочно»
- Сигнал SIGURG отправляется процессу, когда сокет имеет срочные или внеполосные данные, доступные для чтения.
- СИГУСР1 и СИГУСР2
- «Сигнал пользователя 1», «Сигнал пользователя 2»»
- Сигналы SIGUSR1 и SIGUSR2 отправляются процессу для указания условий, определяемых пользователем .
- SIGXCPU
- «Сигнал превысил процессор»
- Сигнал SIGXCPU отправляется процессу, когда он израсходовал ЦП в течение времени, превышающего определенное заранее определенное значение, устанавливаемое пользователем. [20] Поступление сигнала SIGXCPU дает принимающему процессу возможность быстро сохранить любые промежуточные результаты и корректно завершить работу до того, как он будет завершен операционной системой с помощью сигнала SIGKILL.
- СИГКСФЗЗ
- «Сигнализировать превышение размера файла»
- Сигнал SIGXFSZ отправляется процессу, когда он увеличивает размер файла , превышающий максимально допустимый размер .
- СИГВИНЧ
- «Смена окна сигнала»
- Сигнал SIGWINCH отправляется процессу, когда его управляющий терминал меняет свой размер ( окна ) изменение . [21]
Действие по умолчанию
[ редактировать ]Процесс может определить , как обрабатывать входящие сигналы POSIX . Если процесс не определяет поведение сигнала, то обработчик по умолчанию для этого сигнала используется . В таблице ниже перечислены некоторые действия по умолчанию для POSIX-совместимых систем UNIX, таких как FreeBSD , OpenBSD и Linux .
Сигнал | Портативный число | Действие по умолчанию | Описание |
---|---|---|---|
СИГАБРТ | 6 | Завершить (дамп ядра) | Сигнал прерывания процесса |
СИГАЛРМ | 14 | Прекратить | Будильник |
СИГБУС | — | Завершить (дамп ядра) | Доступ к неопределенной части объекта памяти |
СИГЧЛД | — | игнорировать | Дочерний процесс завершен, остановлен или продолжен |
СИГКОНТ | — | Продолжать | Продолжить выполнение, если оно остановлено |
SIGFPE | 8 | Завершить (дамп ядра) | Ошибочная арифметическая операция |
ПОДПИСАТЬСЯ | 1 | Прекратить | Подожди |
ТЮЛЕНЬ | 4 | Завершить (дамп ядра) | Незаконное указание |
СИГНАЛ | 2 | Прекратить | Сигнал прерывания терминала |
СИГКИЛЛ | 9 | Прекратить | Убить (невозможно поймать или проигнорировать) |
СИГПАЙП | 13 | Прекратить | Пишите на трубе, чтобы никто не читал. |
СИГ ОПРОС | — | Прекратить | Опрашиваемое событие |
СИГПРОФ | — | Прекратить | Таймер профилирования истек |
СИГНАЛИЗАЦИЯ | 3 | Завершить (дамп ядра) | Сигнал выхода из терминала |
СИГСЕГВ | 11 | Завершить (дамп ядра) | Неверная ссылка на память |
СИГСТОП | — | Останавливаться | Остановить выполнение (нельзя перехватить или проигнорировать) |
СИГСИС | — | Завершить (дамп ядра) | Неправильный системный вызов |
ЦЕЛЕВОЙ СРОК | 15 | Прекратить | Сигнал завершения |
СИГНАЛЬНАЯ ЛОВУШКА | 5 | Завершить (дамп ядра) | Ловушка трассировки/точки останова |
СИГТСТП | — | Останавливаться | Сигнал остановки терминала |
СИГТТИН | — | Останавливаться | Фоновый процесс пытается прочитать |
СИГТТУ | — | Останавливаться | Фоновый процесс пытается записать |
СИГУСР1 | — | Прекратить | Пользовательский сигнал 1 |
СИГУСР2 | — | Прекратить | Пользовательский сигнал 2 |
ПОБЕДА | — | игнорировать | Внеполосные данные доступны в сокете |
СИГВТАЛРМ | — | Прекратить | Срок действия виртуального таймера истек. |
SIGXCPU | — | Завершить (дамп ядра) | Превышен лимит процессорного времени |
СИГКСФЗЗ | — | Завершить (дамп ядра) | Превышен лимит размера файла |
СИГВИНЧ | — | игнорировать | Размер окна терминала изменен |
- Портативный номер:
- Для большинства сигналов соответствующий номер сигнала определяется реализацией. В этом столбце перечислены числа, указанные в стандарте POSIX. [22]
- Объяснение действий:
- Завершить – аварийное завершение процесса. Процесс завершается со всеми последствиями _exit(), за исключением того, что статус, доступный для wait() и waitpid(), указывает на ненормальное завершение по указанному сигналу.
- Завершить (дамп ядра) — аварийное завершение процесса. Кроме того, могут произойти действия по аварийному завершению, определяемые реализацией, такие как создание файла дампа.
- Игнорировать – игнорировать сигнал.
- Остановить – остановить (или приостановить) процесс.
- Продолжить – продолжить процесс, если он остановлен; в противном случае игнорируйте сигнал.
Разные сигналы
[ редактировать ]Следующие сигналы не указаны в спецификации POSIX . Однако иногда они используются в различных системах.
- СИГЕМТ
- Сигнал SIGEMT отправляется процессу при эмулятора возникновении ловушки .
- СИГИНФО
- Сигнал SIGINFO отправляется процессу, когда состояния ( информация ). от управляющего терминала получен запрос
- СИГПВР
- Сигнал SIGPWR отправляется процессу, когда в системе происходит сбой питания .
- СИГЛОСТ
- Сигнал SIGLOST отправляется процессу, когда блокировка файла потеряна .
- СИГСТКФЛТ
- Сигнал SIGSTKFLT отправляется процессу, когда в сопроцессоре возникает ошибка ( т стека . . е. выталкивание , ) когда стек пуст, или нажатие, когда он заполнен [23] Он определяется, но не используется в Linux, где ошибка стека сопроцессора x87 вместо этого генерирует SIGFPE. [24]
- РЕЛИГИЯ
- Сигнал SIGUNUSED отправляется процессу, когда системный вызов с неиспользуемым выполняется номером системного вызова. В большинстве архитектур это синоним SIGSYS. [23]
- СИГКЛД
- Сигнал SIGCLD является синонимом SIGCHLD. [23]
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ Макилрой, доктор медицины (1987). Читатель Research Unix: аннотированные выдержки из Руководства программиста, 1971–1986 (PDF) (Технический отчет). CSTR. Лаборатории Белла. 139.
- ^ Гальярди, Пьетро. «Программирование на языке C в Plan 9 от Bell Labs» . doc.cat-v.org . Проверено 22 января 2022 г.
- ^ «Сигналы завершения» . Библиотека GNU C) .
- ^ «Сигналы управления заданиями» . Библиотека GNU C.
- ^ «Разные сигналы» . Библиотека GNU C.
- ^ «Базовые спецификации открытой группы, выпуск 6, IEEE Std 1003.1, издание 2004 г.: Системные интерфейсы, глава 2» . pubs.opengroup.org . Проверено 20 декабря 2020 г.
- ^ «signal(7) — страница руководства Linux» . man7.org . Проверено 20 декабря 2020 г.
- ^ «signal-safety(7) — страница руководства Linux» . man7.org . Проверено 20 декабря 2020 г.
- ^ «Базовые спецификации открытой группы, выпуск 6, IEEE Std 1003.1, издание 2004 г.: <signal.h>» . pubs.opengroup.org . Проверено 20 декабря 2020 г.
- ^ Майкл Керриск (25 июля 2009 г.). «сигнал(7)» . Руководство программиста Linux (версия 3.22) . Архивы ядра Linux . Проверено 23 сентября 2009 г.
- ^ "перлипк(1)" . Справочное руководство для программистов на Perl, версия 5.18 . perldoc.perl.org — Официальная документация по языку программирования Perl . Проверено 21 сентября 2013 г.
- ^ «Правильная обработка SIGINT и SIGQUIT» . Проверено 6 октября 2012 года .
- ^ https://manpages.ubuntu.com/manpages/zesty/man2/kill.2.html Архивировано 28 января 2018 г. в разделе Wayback Machine ПРИМЕЧАНИЯ.
- ^ «Процесс инициализации SIGKILL (PID 1)» . Переполнение стека .
- ^ «Может ли root убить процесс инициализации?» . Обмен стеками Unix и Linux .
- ^ «Центр разработки Mac: что нового в Mac OS X: Mac OS X v10.6» . 28 августа 2009 года . Проверено 18 ноября 2017 г.
- ^ «ioctl — управляет устройством STREAM» . POSIX Спецификация системных вызовов . Открытая группа . Проверено 19 июня 2015 г.
- ^ «Что такое «нарушение сегментации»?» . support.microfocus.com . Проверено 22 ноября 2018 г.
- ^ «Отправка системных вызовов пользователям – документация по ядру Linux» . ядро.орг . Проверено 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 .
- «Базовые спецификации открытой группы, выпуск 7, издание 2013 г.» . Открытая группа . Проверено 19 июня 2015 г.
Внешние ссылки
[ редактировать ]- Таблица сигналов Unix, Али Аланджави, Питтсбургский университет
- Man7.org Страница пользователя Signal
- Введение в программирование сигналов Unix. Введение в программирование сигналов Unix на Wayback Machine (архивировано 26 сентября 2013 г.)
- Еще одно введение в программирование сигналов Unix (сообщение в блоге, 2009 г.)
- UNIX и надежные сигналы POSIX, Барис Симсек (хранится в Интернет-архиве )
- Обработчики сигналов от Хеннинга Брауэра