Las señales son mensajes estandarizados que se envían a un programa en ejecución para activar comportamientos específicos, como la finalización del programa o el manejo de errores. Son una forma limitada de comunicación entre procesos (IPC), que se utiliza habitualmente en sistemas operativos Unix , similares a Unix y otros sistemas compatibles con POSIX .
Una señal es una notificación asíncrona que se envía a un proceso o a un hilo específico dentro del mismo proceso para informarle de un evento. Los usos comunes de las señales son interrumpir, suspender, terminar o finalizar un proceso. Las señales se originaron en la década de 1970 en Bell Labs Unix y posteriormente se especificaron en el estándar POSIX .
Cuando se envía una señal, el sistema operativo interrumpe el flujo normal de ejecución del proceso de destino para entregarla. La ejecución puede interrumpirse durante cualquier instrucción no atómica . Si el proceso ha registrado previamente un manejador de señales , se ejecuta dicha rutina. De lo contrario, se ejecuta el manejador de señales predeterminado.
Los programas integrados pueden encontrar útiles las señales para la comunicación entre procesos, ya que las señales destacan por su eficiencia algorítmica .
Las señales son similares a las interrupciones , con la diferencia de que las interrupciones son gestionadas por la CPU y procesadas por el núcleo , mientras que las señales son gestionadas por el núcleo (posiblemente mediante llamadas al sistema) y procesadas por procesos individuales . El núcleo puede pasar una interrupción como señal al proceso que la originó (ejemplos típicos son SIGSEGV , SIGBUS , SIGILL y SIGFPE ).
Historia
- La versión 1 de Unix (1971) tenía llamadas al sistema separadas para capturar interrupciones, salidas y errores de la máquina.
kill(un comando para enviar una señal, por defectoSIGTERM) apareció en la versión 2 (1972).- La versión 4 (1973) combinó todas las trampas en una sola llamada, señal .
- La versión 5 (1974) podía enviar señales arbitrarias. [ 1 ]
- En la versión 7 (1979), cada trampa numerada recibió un nombre simbólico.
- El Plan 9 de Bell Labs (finales de los 80) reemplazó las señales con notas , que permiten enviar cadenas cortas y arbitrarias. [ 2 ]
Enviar señales
La llamada al sistema kill(2) envía una señal específica a un proceso determinado, si los permisos lo permiten. De forma similar, el comando kill(1) permite al usuario enviar señales a los procesos. La función de biblioteca raise(3) envía la señal especificada al proceso actual.
Las excepciones como la división por cero , la violación de segmentación ( SIGSEGV ) y la excepción de punto flotante ( SIGFPE ) provocarán un volcado de memoria y la terminación del programa.
El núcleo puede generar señales para notificar a los procesos sobre eventos. Por ejemplo, se generará SIGPIPE cuando un proceso escriba en una tubería que haya sido cerrada por el lector; por defecto, esto provoca la terminación del proceso, lo cual es conveniente al construir tuberías de shell .
Al escribir ciertas combinaciones de teclas en la terminal de control de un proceso en ejecución, el sistema le envía ciertas señales: [ 3 ]
- Ctrl-C (en versiones antiguas de Unix, DEL) envía una señal INT ("interrupción", SIGINT ); por defecto, esto provoca la finalización del proceso.
- Ctrl-Z envía una señal TSTP ("terminal stop", SIGTSTP ); por defecto, esto provoca que el proceso suspenda su ejecución. [ 4 ]
- Ctrl-\ envía una señal QUIT ( SIGQUIT ); por defecto, esto provoca que el proceso termine y genere un volcado de memoria.
- Ctrl-T (no compatible con todos los sistemas UNIX) envía una señal INFO ( SIGINFO ); por defecto, y si el comando lo admite, esto hace que el sistema operativo muestre información sobre el comando en ejecución. [ 5 ]
Estas combinaciones de teclas predeterminadas en los sistemas operativos modernos se pueden cambiar con el comando stty .
Manejo de señales
Los manejadores de señales se pueden instalar con la llamada al sistema signal(2) o sigaction(2) . Si no se instala un manejador de señales para una señal en particular, se utiliza el manejador predeterminado. De lo contrario, la señal se intercepta y se invoca el manejador de señales. El proceso también puede especificar dos comportamientos predeterminados, sin crear un manejador: ignorar la señal ( SIG_IGN ) y usar el manejador de señales predeterminado ( SIG_DFL ). Hay dos señales que no se pueden interceptar ni manejar: SIGKILL y SIGSTOP .
Riesgos
El manejo de señales es vulnerable a condiciones de carrera . Dado que las señales son asíncronas, otra señal (incluso del mismo tipo) puede llegar al proceso durante la ejecución de la rutina de manejo de señales.
La llamada a sigprocmask(2) permite bloquear y desbloquear la entrega de señales. Las señales bloqueadas no se entregan al proceso hasta que se desbloquean. Las señales que no se pueden ignorar ( SIGKILL y SIGSTOP ) no se pueden bloquear.
Las señales pueden provocar la interrupción de una llamada al sistema en curso, dejando en manos de la aplicación la gestión de un reinicio no transparente .
Los manejadores de señales deben escribirse de manera que no produzcan efectos secundarios no deseados, como la alteración de errno , la alteración de la máscara de señal, el cambio de disposición de la señal y otros cambios en los atributos globales del proceso . El uso de funciones no reentrantes , como malloc o printf , dentro de los manejadores de señales también es inseguro. En particular, la especificación POSIX y la página man signal(7) de Linux exigen que todas las funciones del sistema llamadas directa o indirectamente desde una función de señal sean seguras para señales asíncronas . [ 6 ] [ 7 ] La página man signal-safety(7) proporciona una lista de dichas funciones del sistema seguras para señales asíncronas (prácticamente las llamadas al sistema ). De lo contrario, se trata de un comportamiento indefinido . [ 8 ] Se sugiere simplemente establecer alguna variable en un manejador de señales y probarla en otro lugar. [ 9 ]volatile sig_atomic_t
Los manejadores de señales pueden, en cambio, colocar la señal en una cola y regresar inmediatamente. El hilo principal continuará entonces "sin interrupciones" hasta que se tomen señales de la cola, como en un bucle de eventos . "Sin interrupciones" aquí significa que las operaciones que bloquean pueden regresar prematuramente y deben reanudarse , como se mencionó anteriormente. Las señales deben procesarse desde la cola en el hilo principal y no por grupos de trabajadores , ya que eso reintroduce el problema de la asincronía. Sin embargo, administrar una cola no es posible de manera segura para señales asíncronas con solo sig_atomic_t, ya que solo las lecturas y escrituras individuales en dichas variables están garantizadas como atómicas, no los incrementos o (obtención y) decrementos, como se requeriría para una cola. Por lo tanto, efectivamente, solo se puede poner en cola de forma segura una señal por manejador con sig_atomic_thasta que se haya procesado.
Relación con las excepciones de hardware
La ejecución de un proceso puede generar una excepción de hardware , por ejemplo, si el proceso intenta dividir por cero o si se produce un fallo de página .
En los sistemas operativos tipo Unix , este evento cambia automáticamente el contexto del procesador para iniciar la ejecución de un controlador de excepciones del núcleo . En caso de algunas excepciones, como un fallo de página , el núcleo dispone de información suficiente para gestionar completamente el evento y reanudar la ejecución del proceso.
Sin embargo, para otras excepciones, el núcleo no puede procesarlas de forma inteligente y debe delegar la gestión de excepciones al proceso que generó el fallo. Este delego se logra mediante el mecanismo de señales, en el que el núcleo envía al proceso una señal que corresponde a la excepción actual. Por ejemplo, si un proceso intentara realizar una división entera por cero en una CPU x86 , se generaría una excepción de error de división , lo que provocaría que el núcleo enviara la señal SIGFPE al proceso.
De forma similar, si el proceso intentara acceder a una dirección de memoria fuera de su espacio de direcciones virtuales , el núcleo le notificaría esta infracción mediante una señal SIGSEGV ( señal de violación de segmentación ). La correspondencia exacta entre los nombres de las señales y las excepciones depende, obviamente, de la CPU, ya que los tipos de excepciones difieren entre arquitecturas.
Señales POSIX
La siguiente lista documenta las señales especificadas en la Especificación Única de Unix, versión 5. Todas las señales se definen como macroconstantes en el <signal.h>archivo de cabecera. El nombre de la macroconstante consta del prefijo " SIG " seguido de un nombre mnemotécnico para la señal.
Un proceso puede definir cómo gestionar las señales POSIX entrantes . Si un proceso no define un comportamiento para una señal, se utiliza el controlador predeterminado para dicha señal. La siguiente tabla enumera algunas acciones predeterminadas para sistemas UNIX compatibles con POSIX, como FreeBSD , OpenBSD y Linux .
- Número portátil:
- Para la mayoría de las señales, el número de señal correspondiente está definido por la implementación. Esta columna enumera los números especificados en el estándar POSIX. [ 10 ]
- Explicación de las acciones:
- Terminar – Terminación anormal del proceso. El proceso se termina con todas las consecuencias excepto que el estado puesto a disposición indica una terminación anormal por la señal especificada.
_exit()wait()waitpid() - Finalización (volcado de memoria) : Finalización anormal del proceso. Además, pueden producirse acciones de finalización anormal definidas por la implementación, como la creación de un archivo de volcado de memoria.
- Ignorar – Ignorar la señal.
- Detener – Detener (o suspender) el proceso.
- Continuar : Si el proceso se ha detenido, debe continuar; de lo contrario, ignore la señal.
- SIGABRT ySIGIOT
- La señal SIGABRT se envía a un proceso para indicarle que aborte , es decir, que finalice. Normalmente, el propio proceso inicia la señal al llamar a una función de la biblioteca estándar de C , pero también puede enviarse al proceso desde fuera, como cualquier otra señal.
abort() - SIGIOT indica que la CPU ha ejecutado una instrucción de "trampa" explícita (sin una función definida) o una instrucción no implementada (cuando la emulación no está disponible).
- Nota: El término "trampa de entrada/salida" es un nombre inapropiado para cualquier instrucción de "trampa" de la CPU. Si bien el término refleja el uso inicial de dichas instrucciones, principalmente para implementar funciones de E/S, no están intrínsecamente ligadas a la E/S de los dispositivos y pueden utilizarse para otros fines, como la comunicación entre hosts virtuales y reales.
- Las señales SIGIOT y SIGABRT suelen ser la misma, y la recepción de dicha señal puede indicar cualquiera de las condiciones mencionadas anteriormente.
- SEÑALRM ,SIGVTALRM ySIGPROF
- Las señales SIGALRM , SIGVTALRM y SIGPROF se envían a un proceso cuando se alcanza el límite de tiempo correspondiente. El proceso establece estos límites de tiempo llamando a o . El límite de tiempo para SIGALRM se basa en el tiempo real o de reloj; SIGVTALRM se basa en el tiempo de CPU utilizado por el proceso; y SIGPROF se basa en el tiempo de CPU utilizado por el proceso y por el sistema en su nombre (conocido como temporizador de perfilado ). En algunos sistemas, SIGALRM puede ser utilizado internamente por la implementación de la función.
alarmsetitimersleep - SIGBUS
- La señal SIGBUS se envía a un proceso cuando este provoca un error en el bus . Las condiciones que dan lugar al envío de la señal son, por ejemplo, una alineación incorrecta del acceso a la memoria o una dirección física inexistente.
- SIGCHLD
- La señal SIGCHLD se envía a un proceso cuando un proceso hijo finaliza , se detiene o se reanuda después de haber sido detenido. Un uso común de esta señal es indicar al sistema operativo que libere los recursos utilizados por un proceso hijo tras su finalización, sin necesidad de realizar una llamada explícita al sistema.
wait - CONTACTO SIG
- La señal SIGCONT le indica al sistema operativo que continúe (reinicie) un proceso previamente pausado por la señal SIGSTOP o SIGTSTP . Un uso importante de esta señal es el control de trabajos en el intérprete de comandos de Unix .
- SIGFPE
- La señal SIGFPE se envía a un proceso cuando se detecta una condición excepcional (pero no necesariamente errónea) en el hardware de aritmética de punto flotante o entero. Esto puede incluir división por cero , subdesbordamiento o sobredesbordamiento de punto flotante, sobredesbordamiento de entero , una operación no válida o un cálculo inexacto. El comportamiento puede variar según el hardware.
- REGÍSTRATE
- La señal SIGHUP se envía a un proceso cuando se cierra su terminal de control. Originalmente, se diseñó para notificar al proceso sobre una caída de la línea serie (un hangup ). En los sistemas modernos, esta señal generalmente significa que se ha cerrado la terminal virtual o pseudoterminal de control. [ 11 ] Muchos demonios (que no tienen terminal de control) interpretan la recepción de esta señal como una solicitud para recargar sus archivos de configuración y vaciar/reabrir sus archivos de registro en lugar de salir. [ 12 ] nohup es un comando para hacer que un comando ignore la señal.
- SIGLO
- La señal SIGILL se envía a un proceso cuando intenta ejecutar una instrucción ilegal , mal formada, desconocida o privilegiada .
- INTELIGENCIA DE SEÑALES
- La señal SIGINT es enviada a un proceso por su terminal de control cuando un usuario desea interrumpirlo . Esto generalmente se inicia presionando + , pero en algunos sistemas, se puede usar el carácter " supr " o la tecla " break ". [ 13 ]CtrlC
- SIGKILL
- La señal SIGKILL se envía a un proceso para provocar su terminación inmediata ( kill ). A diferencia de SIGTERM y SIGINT , esta señal no puede ser interceptada ni ignorada, y el proceso receptor no puede realizar ninguna limpieza al recibirla. Se aplican las siguientes excepciones:
- Los procesos zombie no pueden ser eliminados, ya que están muertos y esperando a que sus procesos padres los eliminen.
- Los procesos que se encuentran en estado bloqueado no se detendrán hasta que vuelvan a activarse.
- El proceso init es especial: no recibe señales que no desea manejar y, por lo tanto, puede ignorar SIGKILL. [ 14 ] Una excepción a esta regla se da cuando se rastrea init en Linux. [ 15 ] [ 16 ]
- Un proceso en estado de suspensión ininterrumpida puede no finalizar (y liberar sus recursos) incluso al recibir la señal SIGKILL . Este es uno de los pocos casos en los que puede ser necesario reiniciar un sistema UNIX para solucionar un problema temporal de software.
- SIGKILL se utiliza como último recurso al finalizar procesos en la mayoría de los procedimientos de apagado del sistema si no finalizan voluntariamente en respuesta a SIGTERM . Para acelerar el procedimiento de apagado del ordenador, Mac OS X 10.6, también conocido como Snow Leopard , enviará SIGKILL a las aplicaciones que se hayan marcado como "limpias", lo que resultará en tiempos de apagado más rápidos y, presumiblemente, sin efectos negativos. [ 17 ] El comando tiene un efecto similar, aunque peligroso, cuando se ejecuta, por ejemplo, en Linux; no permite que los programas guarden datos no guardados. Tiene otras opciones y, cuando no las tiene, utiliza la señal SIGTERM, que es más segura.
killall -9 - SIGPIPE
- La señal SIGPIPE se envía a un proceso cuando intenta escribir en una tubería sin que haya ningún proceso conectado al otro extremo.
- ENCUESTA DE SIG
- La señal SIGPOLL se envía cuando ocurre un evento en un descriptor de archivo monitoreado explícitamente. [ 18 ] Su uso efectivo conduce a realizar solicitudes de E/S asíncronas, ya que el kernel sondeará el descriptor en lugar del llamador. Proporciona una alternativa al sondeo activo .
- SIGRTMIN aSIGRTMAX
- Las señales SIGRTMIN a SIGRTMAX están diseñadas para ser utilizadas con fines definidos por el usuario. Son señales en tiempo real .
- SIGQUIT
- La señal SIGQUIT es enviada a un proceso por su terminal de control cuando el usuario solicita que el proceso finalice y realice un volcado de memoria .
- SIGSEGV
- La señal SIGSEGV se envía a un proceso cuando realiza una referencia de memoria virtual no válida o un fallo de segmentación , es decir, cuando realiza una violación de segmentación . [ 19 ]
- SIGSTOP
- La señal SIGSTOP indica al sistema operativo que detenga un proceso para su posterior reanudación.
- SIGSYS
- La señal SIGSYS se envía a un proceso cuando pasa un argumento incorrecto a una llamada al sistema . En la práctica, este tipo de señal rara vez se encuentra, ya que las aplicaciones dependen de bibliotecas (por ejemplo, libc ) para realizar la llamada por ellas. Las aplicaciones que infringen las reglas de seguridad Seccomp de Linux configuradas para restringirlas pueden recibir SIGSYS . SIGSYS también se puede usar para emular llamadas al sistema externas, por ejemplo, emular llamadas al sistema de Windows en Linux. [ 20 ]
- SIGTERM
- La señal SIGTERM se envía a un proceso para solicitar su terminación . A diferencia de la señal SIGKILL , el proceso puede capturarla, interpretarla o ignorarla. Esto permite que el proceso realice una terminación segura, liberando recursos y guardando el estado si es necesario. SIGINT es prácticamente idéntica a SIGTERM .
- SIGTSTP
- La señal SIGTSTP es enviada a un proceso por su terminal de control para solicitarle que se detenga ( terminal stop ). Generalmente , el usuario la inicia pulsando la tecla + . A diferencia de SIGSTOP , el proceso puede registrar un manejador de señales o ignorarla.CtrlZ
- SIGTTIN ySIGTTOU
- Las señales SIGTTIN y SIGTTOU se envían a un proceso cuando intenta leer o escribir, respectivamente , en la terminal mientras se ejecuta en segundo plano . Normalmente, estas señales solo las reciben los procesos bajo control de trabajo ; los demonios no tienen terminales de control y, por lo tanto, nunca deberían recibirlas.
- SIGTRAP
- La señal SIGTRAP se envía a un proceso cuando se produce una excepción (o trampa ): una condición de la que un depurador ha solicitado ser informado , por ejemplo, cuando se ejecuta una función en particular o cuando cambia el valor de una variable en particular .
- SIGURG
- La señal SIGURG se envía a un proceso cuando un socket tiene datos urgentes o fuera de banda disponibles para leer.
- SIGUSR1 ySIGUSR2
- Las señales SIGUSR1 y SIGUSR2 se envían a un proceso para indicar condiciones definidas por el usuario .
- CPU SIGX
- La señal SIGXCPU se envía a un proceso cuando este ha utilizado la CPU durante un tiempo que excede un valor predeterminado configurable por el usuario. [ 21 ] La llegada de una señal SIGXCPU le brinda al proceso receptor la oportunidad de guardar rápidamente cualquier resultado intermedio y finalizar correctamente, antes de que el sistema operativo lo termine mediante la señal SIGKILL .
- SIGXFSZ
- La señal SIGXFSZ se envía a un proceso cuando este aumenta el tamaño de un archivo y este excede el tamaño máximo permitido .
- SIGWINCH
- La señal SIGWINCH se envía a un proceso cuando su terminal de control cambia de tamaño (un cambio de ventana ) . [ 22 ]
Señales diversas
Las siguientes señales no están especificadas en la especificación POSIX . Sin embargo, a veces se utilizan en diversos sistemas.
- SIGEMT
- La señal SIGEMT se envía a un proceso cuando se produce una interrupción del emulador . Si bien un emulador generalmente se refiere a un software que ejecuta otros programas, en este caso significa que un programa ejecutó una instrucción de llamada al supervisor (EMT era la instrucción para este propósito en la serie de computadoras DEC PDP-11 ).
- INFORMACIÓN DE SEÑAL
- La señal SIGINFO se envía a un proceso cuando se recibe una solicitud de estado ( info ) del terminal de control.
- SIGPWR
- La señal SIGPWR se envía a un proceso cuando el sistema experimenta un fallo de alimentación .
- SIGLOST
- La señal SIGLOST se envía a un proceso cuando se pierde el bloqueo de un archivo .
- SIGSTKFLT
- La señal SIGSTKFLT se envía a un proceso cuando el coprocesador experimenta un fallo de pila (es decir , se extrae un elemento cuando la pila está vacía o se inserta uno cuando está llena). [ 23 ] Está definida por Linux, pero no se utiliza en él, donde un fallo de pila del coprocesador x87 generará SIGFPE en su lugar. [ 24 ]
- SIGUNUSED
- La señal SIGUNUSED se envía a un proceso cuando se realiza una llamada al sistema con un número de llamada al sistema no utilizado . En la mayoría de las arquitecturas, es sinónimo de SIGSYS . [ 23 ]
- SIGCLD
- La señal SIGCLD es sinónimo de SIGCHLD . [ 23 ]
Véase también
Referencias
- ↑ McIlroy, MD (1987). Un lector de Research Unix: extractos anotados del Manual del programador, 1971–1986 (PDF) (Informe técnico). CSTR. Bell Labs. 139.
- ↑ Gagliardi, Pietro. "Programación en C en Plan 9 de Bell Labs" . doc.cat-v.org . Consultado el 22 de enero de 2022 .
- ↑ "Señales de terminación" . La biblioteca C de GNU) .
- ↑ "Señales de control de trabajo" . La biblioteca GNU C.
- ↑ "Señales varias" . La biblioteca GNU C.
- ↑ "Especificaciones básicas de The Open Group, número 6, IEEE Std 1003.1, edición de 2004: Interfaces del sistema, capítulo 2" . pubs.opengroup.org . Consultado el 20 de diciembre de 2020 .
- ↑ "signal(7) - Página del manual de Linux" . man7.org . Consultado el 20 de diciembre de 2020 .
- ↑ "signal-safety(7) - Página del manual de Linux" . man7.org . Consultado el 20 de diciembre de 2020 .
- ↑ "Especificaciones básicas de The Open Group, número 6, IEEE Std 1003.1, edición de 2004: <signal.h>" . pubs.opengroup.org . Consultado el 20 de diciembre de 2020 .
- ↑ "IEEE Std 1003.1-2017 - kill" . IEEE, Open Group.
La correspondencia entre los valores enteros y el valor
sig
utilizado se muestra en la siguiente lista. Los efectos de especificar cualquier
número de señal
distinto a los que se enumeran a continuación no están definidos.
- ↑ Michael Kerrisk (25 de julio de 2009). "signal(7)" . Manual del programador de Linux (versión 3.22) . Archivos del kernel de Linux . Consultado el 23 de septiembre de 2009 .
- ↑ "perlipc(1)" . Guía de referencia para programadores de Perl, versión 5.18 . perldoc.perl.org - Documentación oficial del lenguaje de programación Perl . Consultado el 21 de septiembre de 2013 .
- ↑ "Manejo adecuado de SIGINT y SIGQUIT" . Consultado el 6 de octubre de 2012 .
- ↑ https://manpages.ubuntu.com/manpages/zesty/man2/kill.2.html Archivado el 28 de enero de 2018 en la sección NOTAS de Wayback Machine
- ↑ "Proceso de inicio SIGKILL (PID 1)" . Stack Overflow .
- ↑ "¿Puede el usuario root matar el proceso init?" . Unix & Linux Stack Exchange .
- ↑ "Mac Dev Center: Novedades en Mac OS X: Mac OS X v10.6" . 28 de agosto de 2009. Consultado el 18 de noviembre de 2017 .
- ↑ "ioctl - controla un dispositivo STREAM" . Especificación de llamadas al sistema POSIX . The Open Group . Consultado el 19 de junio de 2015 .
- ↑ "¿Qué es una "violación de segmentación"?" . support.microfocus.com . Consultado el 22 de noviembre de 2018 .
- ↑ "Despacho de usuarios de llamadas al sistema: la documentación del kernel de Linux" . kernel.org . Consultado el 11 de febrero de 2021 .
- ↑ "getrlimit, setrlimit - control del consumo máximo de recursos" . Especificación de llamadas al sistema POSIX . The Open Group . Consultado el 10 de septiembre de 2009 .
- ↑ Clausecker, Robert (19 de junio de 2017). "0001151: Introducir la nueva señal SIGWINCH y las funciones tcsetsize(), tcgetsize() para obtener/establecer el tamaño de la ventana del terminal" . Austin Group Defect Tracker . Austin Group . Recuperado el 12 de octubre de 2017.
Aceptado como marcado
. - 1 2 3 "signal(7) — Páginas del manual de Linux" . manpages.courier-mta.org . Consultado el 22 de noviembre de 2018 .
- ↑ "Linux 3.0 x86_64: ¿Cuándo se activa SIGSTKFLT?" . Stack Overflow .
- Stevens, W. Richard (1992). Programación avanzada en el entorno UNIX® . Reading, Massachusetts: Addison Wesley. ISBN 0-201-56317-7.
- "Especificaciones base de The Open Group, edición 8, IEEE Std 1003.1™-2024" . The Open Group . Consultado el 2 de marzo de 2025 .
Enlaces externos
- Tabla de señales de Unix, Ali Alanjawi, Universidad de Pittsburgh
- Página de Signal Man en Man7.org
- Introducción a la programación de señales Unix Introducción a la programación de señales Unix en Wayback Machine (archivado el 26 de septiembre de 2013)
- Otra introducción a la programación de señales en Unix (entrada de blog, 2009)
- UNIX y señales POSIX fiables por Baris Simsek (almacenado en Internet Archive )
- Manipuladores de señales por Henning Brauer
- Comunicación entre procesos
- Flujo de control