Es una vieja pregunta, pero aún así.
Los subprocesos POSIX en Linux en glibc (NPTL) se implementan utilizando dos señales en tiempo real. Están ocultos para el usuario (mediante el ajuste de las constantes numéricas mínimas/máximas). Todos los eventos en los que la llamada a la biblioteca debe propagarse a todos los subprocesos (como setuid ) se realizan a través de estos:el subproceso de llamada envía una señal a todos los subprocesos para aplicar el cambio, espera el reconocimiento y continúa.
E/S asíncrona.
Las señales en tiempo real son el mecanismo del kernel para informar a su sistema cuando se ha completado una operación de E/S.
struct aiocb establece la conexión entre una solicitud de E/S asíncrona y un número de señal.
En primer lugar, tenga en cuenta que la respuesta de Ben es correcta. Por lo que puedo decir, el propósito de las señales en tiempo real en POSIX es como un mecanismo de entrega en tiempo real para AIO, notificaciones de cola de mensajes, vencimientos de temporizadores y señales definidas por la aplicación (tanto internas como entre procesos).
Dicho esto, las señales en general son una forma realmente mala de hacer las cosas:
- Los controladores de señales son asincrónicos y, a menos que se asegure de que no interrumpen una función no segura de señal asíncrona, solo pueden usar funciones seguras de señal asíncrona, lo que limita severamente lo que pueden hacer.
- Los manejadores de señales son de estado global. Una biblioteca no puede usar señales sin un contrato con el programa de llamada con respecto a qué señales puede usar, si puede hacer que interrumpan las llamadas al sistema, etc. Y, en general, el estado global es simplemente Algo malo .
- Si usa
sigwait(o Linuxsignalfdextensión) en lugar de controladores de señales para procesar señales, no son mejores que otros mecanismos de notificación/IPC y aún son potencialmente peores.
La E/S asíncrona se logra mucho mejor ignorando la API POSIX AIO mal diseñada y simplemente creando un subproceso para realizar una E/S de bloqueo normal y llamando a pthread_cond_signal o sem_post cuando termine la operación. O, si puede permitirse un poco de costo de rendimiento, puede incluso reenviarse los datos recién leídos a través de una tubería o un par de enchufes, y hacer que el subproceso principal procese archivos normales de lectura asíncrona con select o poll tal como lo haría con enchufes/tuberías/ttys.