Chi utilizza i segnali POSIX in tempo reale e perché?

È una vecchia domanda, ma ancora.

I thread POSIX su Linux in glibc (NPTL) sono implementati utilizzando due segnali in tempo reale. Sono nascosti all'utente (regolando le costanti del numero min/max). Tutti gli eventi in cui la chiamata alla libreria deve essere propagata a tutti i thread (come setuid ) vengono eseguiti tramite quelli:il thread chiamante invia un segnale a tutti i thread per applicare la modifica, attende il riconoscimento e continua.

I/O asincrono.

I segnali in tempo reale sono il meccanismo con cui il kernel informa il tuo sistema quando un'operazione di I/O è stata completata.

struct aiocb effettua la connessione tra una richiesta I/O asincrona e un numero di segnale.

Prima di tutto, nota che la risposta di Ben è corretta. Per quanto ne so, l'intero scopo dei segnali in tempo reale in POSIX è come meccanismo di consegna in tempo reale per AIO, notifiche sulla coda dei messaggi, scadenze del timer e segnali definiti dall'applicazione (sia interni che inter-processo).

Detto questo, i segnali in generale sono un pessimo modo di fare le cose:

• I gestori di segnale sono asincroni e, a meno che tu non assicuri che non interrompano una funzione async-signal-unsafe, possono utilizzare solo funzioni async-signal-safe, il che limita fortemente ciò che possono fare.
• I gestori di segnale sono stati globali. Una libreria non può utilizzare i segnali senza un contratto con il programma chiamante riguardo a quali segnali è consentito utilizzare, se è consentito farli interrompere le chiamate di sistema, ecc. E in generale, lo stato globale è solo una brutta cosa .
• Se usi sigwait (o Linux signalfd estensione) piuttosto che gestori di segnale per elaborare i segnali, non sono migliori di altri IPC/meccanismi di notifica, e ancora potenzialmente peggiori.

L'IO asincrono viene realizzato molto meglio ignorando l'API AIO POSIX mal progettata e semplicemente creando un thread per eseguire il normale IO di blocco e chiamare pthread_cond_signal o sem_post al termine dell'operazione. Oppure, se puoi permetterti un po' di costo delle prestazioni, puoi persino inoltrare a te stesso i dati appena letti tramite una pipe o una coppia di socket e fare in modo che il thread principale elabori in modo asincrono file regolari con select o poll proprio come faresti con socket/pipes/ttys.