Ça sert à ce pour quoi c'est faire. Lancer un signal à un programme. Pour l'arrêter c'est beaucoup utiliser, pour demander des rechargements de configuration aussi. A savoir quand un processus fils est mort.
C'est la solution la plus simple et la plus légère de toutes les IPC, mais tu en a pleins d'autres :
les pipes nommées ou non
les socket unix ou tcp
les fichiers
la mémoire partagée
et un paquet d'autres plus ou moins spécifique (genre pour l'un des plus sophistiqué sous linux : dbus).
À noter, je crois que personne ne l'a cité, mais tu n'a aucune garantie que ton signal arrive sur le processus que tu attends, il me semble. Il peut être mort et son pid être réutilisé entre le moment où tu as lu le pid et le moment où tu envoi le signal.
[^] # Re: Utilisation
Posté par barmic 🦦 . En réponse au journal SIGUSR1, SIGUSR2,..., SIGUSR_N ?. Évalué à 3.
Ça sert à ce pour quoi c'est faire. Lancer un signal à un programme. Pour l'arrêter c'est beaucoup utiliser, pour demander des rechargements de configuration aussi. A savoir quand un processus fils est mort.
C'est la solution la plus simple et la plus légère de toutes les IPC, mais tu en a pleins d'autres :
et un paquet d'autres plus ou moins spécifique (genre pour l'un des plus sophistiqué sous linux : dbus).
À noter, je crois que personne ne l'a cité, mais tu n'a aucune garantie que ton signal arrive sur le processus que tu attends, il me semble. Il peut être mort et son pid être réutilisé entre le moment où tu as lu le pid et le moment où tu envoi le signal.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll