I segnali hanno lo scopo di fornire una forma rudimentale di controllo su un processo, non come un meccanismo IPC. I segnali hanno diversi problemi se usati come qualsiasi altra cosa:
-
Molte chiamate di sistema verranno interrotte da un segnale e richiedono una gestione speciale.
-
Di conseguenza, molto codice in circolazione non è sicuro dal punto di vista del segnale.
-
I segnali non hanno alcun tipo di contenuto di dati, tranne se stessi. Questo li rende per lo più inutili come metodo di passaggio dei messaggi.
-
C'è solo così tanto che puoi fare in un gestore di segnale.
-
Ancora più importante, i segnali successivi dello stesso tipo non vengono messi in coda:vengono uniti in un'unica istanza.
-
Ancora più importante, non vi è alcuna garanzia che i segnali vengano consegnati nello stesso ordine in cui sono stati generati . Dalla pagina di manuale:
Al contrario, se più segnali standard sono in attesa di un processo, l'ordine in cui vengono consegnati non è specificato .
Potresti in teoria essere in grado di impostare una sorta di canale utilizzando diversi segnali che vanno avanti e indietro, con alcuni che agiscono come una sorta di riconoscimento, ma nessuna persona sana di mente vorrebbe tentare qualcosa del genere. Potresti anche usare i segnali di fumo invece...
È possibile fare IPC (comunicazione tra processi) usando signal catch e signal raise?
Sì e no. Considerando solo i segnali, puoi inviare un segnale a un altro processo, ma non puoi inviare nient'altro che un semplice segnale.
Voglio passare messaggi anche con questo segnale. Posso farlo? È possibile?
No, non nel modo in cui stai cercando di farlo. È possibile utilizzare socket, file, pipe o pipe con nome per eseguire questa operazione. Se vuoi saperne di più su UNIX IPC, leggi Programmazione avanzata nell'ambiente UNIX.
No, non cercare di utilizzare i segnali per questo. Non è possibile allegare dati aggiuntivi con segnali diversi dalla struttura siginfo. Il problema principale con l'utilizzo dei segnali è che così poco è sicuro per il segnale. Devi evitare quasi tutte le routine di runtime C e assicurarti che il programma ricevente esegua controlli EINTR su tutte le sue chiamate al kernel. L'unica cosa che puoi dire su quando si verifica un segnale è che non sarà quando te lo aspetti (un po' come l'Inquisizione spagnola).
Ti suggerisco di esaminare gli altri meccanismi IPC, come memoria condivisa, code di messaggi, fifo (named pipe) e socket.