Questions sur les signaux

Version imprimable

30/07/2010, 16h20
syl1405

Questions sur les signaux

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...) 8O

Merci !
30/07/2010, 20h05
Bayard

Est-ce réellement une question sur le langage C ?
30/07/2010, 21h07
ram-0000

Citation:

Envoyé par syl1405

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.

Citation:

Envoyé par syl1405

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.

Citation:

Envoyé par syl1405

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

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).
31/07/2010, 12h54
Obsidian

Bonjour,

Citation:

Envoyé par Bayard

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).

Citation:

Envoyé par syl1405

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.
03/08/2010, 09h38
syl1405

Merci pour ces informations !

Citation:

Envoyé par Obsidian

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 !
03/08/2010, 09h48
ram-0000

Citation:

Envoyé par syl1405

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 ?

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:

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);
}

03/08/2010, 11h48
syl1405

Citation:

Envoyé par ram-0000

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 !
03/08/2010, 12h04
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".
03/08/2010, 13h41
syl1405

Citation:

Envoyé par ram-0000

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 ?
03/08/2010, 13h52
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é
03/08/2010, 13h55
syl1405

Citation:

Envoyé par ram-0000

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 !
03/08/2010, 13h58
Obsidian

Bonjour,

Citation:

Envoyé par syl1405

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.