Sobre la entrega de señales, TLPI establece que las señales son "normalmente" entregado cuando una tarea está próximo programado, cuando se cambia de modo de núcleo a modo de usuario, o "inmediatamente" cuando la tarea se está ejecutando (presumiblemente "inmediatamente "tendría que suceder disparando primero una interrupción, de lo contrario, ¿cómo podría hacer eso?". Bueno, sea lo que sea que esto signifique, no es estrictamente vinculante, pero está muy cerca de lo que sucede.
Debe distinguir entre señales "normales" y en tiempo real, así como entre señales "normales" que se generan de forma síncrona, la mayoría de las veces debido a un evento de hardware (por ejemplo, falla de segmentación) y las que no (se generó asnychronously).
señales en tiempo real son cola señales, normales no son. Eso significa que la implementación de señales normales probablemente sea más bien algo así como una palabra por tarea que sirve como máscara de bits.
Generar una señal "normal" significa establecer un bit, y cuando el SO luego decide si una señal debe ser entregada, prueba la palabra contra cero, y si es necesario determina qué bit (s) se establecieron, y llama al gestor (es) de señales, en su caso, en consecuencia.
La única razón práctica por la cual uno necesita saber esto es porque es posible "perder" las señales. Si se generan dos o más señales antes de que se entregue la primera, sigue siendo solo una señal.
La implementación de señales en tiempo real (que son necesarias para cola hasta una longitud dependiente de la implementación) es obviamente mucho más complicada.
Las señales que suceden debido a un evento de hardware (por ejemplo segfault) se generan de forma síncrona, del mismo modo que si el proceso se llama kill (capítulo 22.4 TLPI), es decir, se entregan "inmediatamente" por dos motivos. En primer lugar, no tiene sentido hacer otra cosa, y segundo, ya hay un cambio de kernel/usuario que ocurre cuando el controlador de trampa regresa. Entonces la entrega siempre es "inmediata" de todos modos.
Básicamente, las señales son asíncronas. Confían en los manejadores de señal para ejecutar el código cuando se recibe una señal porque nunca se sabe cuándo eso se debe a factores tales como el programador del proceso. La latencia de enviar una señal se basa en la interrupción de hardware/software, que se basa en la velocidad del reloj.
Si desea saber cómo se implementa algo en Linux, consulte los estándares POSIX.
gran información sobre Señales:
http://www.gnu.org/software/libc/manual/html_node/index.html#toc_Signal-Handling
Cuando se genera una señal, se convierte en pendientes. Normalmente permanece pendiente por solo un corto período de tiempo y luego es entregado al proceso que fue señalado. Sin embargo, si ese tipo de señal es actualmente bloqueado, puede permanecer pendiente indefinidamente - hasta que las señales de ese tipo sean desbloqueadas. Una vez desbloqueado, se entregará inmediatamente.
Otro extracto:
Cuando se entrega la señal, ya sea de inmediato o después de un largo de retardo, se toma la acción especificada para esa señal.