Discussion :

[syl1405]

Bonjour,

Je fait un traitement de signaux sur un programme, j'utilise actuellement SIGUSR1 et SIGUSR2. J'aurais besoin d'utiliser un autre signal, seulement quand je lis la liste des signaux dans les man, ils ont tous une utilité (tuer un process, informer la fin d'un fils etc ...).

Je me demandais donc s'il était possible de créer un signal quelconque ? J'ai essayé qqchose du style kill -435, mais la référence du signal n'existe pas.

Sinon, quel signal choisir pour être sûr que je le reçois bien de mon programme ? A part SIGUSR1 et SIGUSR2, je ne vois pas ...

Dernière question : pourquoi y a-t-il autant de signaux pour tuer un processus ??? (SIGABRT, SIGALRM, SIGINT etc...)

Merci !

[Bayard]

Est-ce réellement une question sur le langage C ?

[ram-0000]

Je me demandais donc s'il était possible de créer un signal quelconque ? J'ai essayé qqchose du style kill -435, mais la référence du signal n'existe pas.

Non, tu ne peux pas, les signaux utilisables sont les signaux existant et c'est tout.

Sinon, quel signal choisir pour être sûr que je le reçois bien de mon programme ? A part SIGUSR1 et SIGUSR2, je ne vois pas ...

Tous les signaux sont reçus par ton programme. Tous ces signaux peuvent potentiellement être envoyés par le noyau à ton programme sauf SIGUSR1 et SIGUSR2 et c'est pour cela qu'on les utilise. Maintenant, si tu es sûr que tu ne recevras jamais le signal SIGALRM, tu peux aussi l'utiliser, c'est pas interdit mais c'est une démarche qui risque de surprendre le prochain lecteur de ton code.

Dernière question : pourquoi y a-t-il autant de signaux pour tuer un processus ??? (SIGABRT, SIGALRM, SIGINT etc...)

Il y a des signaux différents pour des événements différents. Maintenant, le traitement par défaut du process en cas de survenue d'un signal est souvent de s'arrêter (mais pas toujours).

[Obsidian]

Bonjour,

Est-ce réellement une question sur le langage C ?

Oui, car ils sont définis dans la norme (j'étais le premier à penser qu'ils étaient purement UNIX).

Je fait un traitement de signaux sur un programme, j'utilise actuellement SIGUSR1 et SIGUSR2. J'aurais besoin d'utiliser un autre signal, seulement quand je lis la liste des signaux dans les man, ils ont tous une utilité (tuer un process, informer la fin d'un fils etc ...).

Dernière question : pourquoi y a-t-il autant de signaux pour tuer un processus ?

Il est important de comprendre que les signaux Unix ne servent pas en eux-mêmes à faire du message passing. Ils ne servent pas à véhiculer une donnée d'un processus à un autre, mais à interrompre ledit processus s'il se passe quelque chose au niveau système (donc hors de portée du processus) qui puisse l'empêcher de continuer.

Par exemple, SIGPIPE se déclenche lorsque ton processus écrit dans un tube dont le lecteur a brutalement disparu ou l'a refermé sans crier gare. C'est un mécanisme qui implique deux processus indépendant et une partie du noyau. On sait que l'événement peut se produire, d'où l'existence d'un signal dédié, mais il n'est pas censé avoir lieu en temps normal et, en tout état de cause, on ne peut pas savoir à l'avance à quel moment il le fera.

C'est aussi pour cela que la plupart des signaux provoquent la mort du processus : en principe, le processus ne peut pas continuer s'il n'a pas été prévu pour. Mais si tu as des raisons de penser qu'un de ces événements peut se produire et que tu saurais le gérer, alors tu peux installer un handler de signal pour le prendre en main.

Il faut aussi retenir qu'un signal UNIX est relativement « violent », dans le sens où il préempte le processus et passe un certain temps en mode noyau. Ça en fait aussi un mécanisme intrinsèquement lent, qu'il ne faut donc utiliser que de manière occasionnelle.

Il y a déjà eu plein de discussions à ce sujet :

http://www.developpez.net/forums/d70...envoi-signaux/
http://www.developpez.net/forums/d68...ation-signaux/
http://www.developpez.net/forums/d65...obleme-ctrl-z/
http://www.developpez.net/forums/d88...lemes-signaux/
http://www.developpez.net/forums/d89...x/#post5057907
http://www.developpez.net/forums/d89.../fork-signaux/
http://www.developpez.net/forums/d88...ter/aide-fork/
http://www.developpez.net/forums/d89...l/#post5078743
http://www.developpez.net/forums/d89...terminate-cpp/
http://www.developpez.net/forums/d90...l/#post5138476


Note enfin que « signal » est un terme générique qui est défini de mamnière spécifique dans chaque environnement : un signal UNIX n'a rien à voir avec un signal GTK, par exemple.

Si tu as besoin de faire communiquer deux processus, il y a plein de mécanismes à ta disposition : le pipe, les sockets, sous SysV il y a les sémaphores, la mémoire partagée, les files de messages. Et une fois que tu as épuisé toutes ces possibilités, tu peux utiliser les mécanismes construits par les bibliothèques de plus haut niveau si tu les utilises.

[syl1405]

Merci pour ces informations !

Si tu as besoin de faire communiquer deux processus, il y a plein de mécanismes à ta disposition : le pipe, les sockets, sous SysV il y a les sémaphores, la mémoire partagée, les files de messages. Et une fois que tu as épuisé toutes ces possibilités, tu peux utiliser les mécanismes construits par les bibliothèques de plus haut niveau si tu les utilises.

En fait, j'ai un programme principal en C++ qui s'exécute, et plusieurs scripts bash qui y sont exécutés régulièrement. Et un de ces scripts doit renvoyer un état (vrai ou faux) au processus principal (mais il n'est appelé qu'occasionnellement). Je n'ai pensé qu'aux signaux.
Concernant les sémaphores, c'est un mécanisme de synchronisation, et l'utilisation que je fais des signaux n'est pas faite pour synchroniser les processus.

Le pipe me plaît beaucoup plus ! Je n'y avais pas pensé

Merci beaucoup !

[ram-0000]

Et un de ces scripts doit renvoyer un état (vrai ou faux) au processus principal (mais il n'est appelé qu'occasionnellement). Je n'ai pensé qu'aux signaux.

Si tu n'as que 2 valeurs possibles, pourquoi ne pas regarder le code de retour du script ?

[jabbounet]

C'est le programme c++ qui lance les scripts?

Dans ce cas tu peux récupérer la sortie grace a des fonction du type popen
http://www.opengroup.org/onlinepubs/...ons/popen.html

Exemple tiré de http://tldp.org/LDP/lpg/node12.html

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
 
/*****************************************************************************
 Excerpt from "Linux Programmer's Guide - Chapter 6"
 (C)opyright 1994-1995, Scott Burkett
 ***************************************************************************** 
 MODULE: popen2.c
 *****************************************************************************/
 
#include <stdio.h>
 
int main(void)
{
        FILE *pipein_fp, *pipeout_fp;
        char readbuf[80];
 
        /* Create one way pipe line with call to popen() */
        if (( pipein_fp = popen("ls", "r")) == NULL)
        {
                perror("popen");
                exit(1);
        }
 
        /* Create one way pipe line with call to popen() */
        if (( pipeout_fp = popen("sort", "w")) == NULL)
        {
                perror("popen");
                exit(1);
        }
 
        /* Processing loop */
        while(fgets(readbuf, 80, pipein_fp))
                fputs(readbuf, pipeout_fp);
 
        /* Close the pipes */
        pclose(pipein_fp);
        pclose(pipeout_fp);
 
        return(0);
}

[syl1405]

Si tu n'as que 2 valeurs possibles, pourquoi ne pas regarder le code de retour du script ?

Parce que j'ai 2 threads qui s'exécutent simultanément et donc la lecture de errno peut être faussée.

EDIT : Pardon pour la bêtise ... dixit man errno :
"errno est locale à un thread ; lui affecter une valeur dans un thread ne modifie pas sa valeur dans les autres threads. "

Je ne connaissais pas la fonction popen ... je vais regarder ça de plus près J'ai implémenté le pipe, ça marche bien, mais popen me fera sûrement économiser des lignes

Merci !

[ram-0000]

Je ne parlais pas de errno.

Lorsque tu lances un "machin" (je ne sais pas s'il s'agit d'un binaire ou d'un script) et que tu le lances par system() ou CreateProcess() ou execve(), il est toujours possible le code de retour du programme appelé.

Si ton script fait "exit 2" ou "return 2", tu peux récupérer ce "2".

[syl1405]

Lorsque tu lances un "machin" (je ne sais pas s'il s'agit d'un binaire ou d'un script) et que tu le lances par system() ou CreateProcess() ou execve(), il est toujours possible le code de retour du programme appelé.

Si ton script fait "exit 2" ou "return 2", tu peux récupérer ce "2".

Actuellement, j'exécutais les scripts avec execlp(). Lorsque je fais un "exit 2", il me faut lire stderr dans mon code C pour le lire non ?

[ram-0000]

Tu récupères le code de retour du process avec la fonction wait().

Ici, tu as un exemple avec execve() qui récupère le code de retour du programme appelé

[syl1405]

Tu récupères le code de retour du process avec la fonction wait().

Ah oui, j'utilisais déjà waitpid(), mais je pensais que le status correspondait simplement à "le fils est fini correctement" ou pas ... Bon ça simplifie tout alors !

Merci !

[Obsidian]

Bonjour,

Actuellement, j'exécutais les scripts avec execlp(). Lorsque je fais un "exit 2", il me faut lire stderr dans mon code C pour le lire non ?

Non, non. Lorsque tu fais exit(2) ou, d'une manière générale, lorsque tu fais un return dans ta fonction main(), tu renvoies un code de retour comme si tu quittais une fonction ordinaire mais, à ce stade, ton programme n'existe déjà plus.

Il appartient donc à ton processus père d'utiliser l'appel-système wait() pour reconnaître la dépouille de son fils :-) sans quoi celui-ci resterait zombie (état Z : le processus est mort et inactif, mais ses ressources restent encore en mémoire jusqu'à ce que le père s'en occupe).

En passant à wait() l'adresse d'une variable de type int, l'appel système va y déposer le code de retour de ton processus et d'autres flags, que tu pourras retrouver à l'aide des macros décrites dans la man page.