« Programmation C/Gestion des signaux » : différence entre les versions

Les signaux permettent une communication, assez sommaire, entre le système et un processus, ou entre différents processus. Cette communication est sommaire, car un ''signal'' ne porte qu'une seule information: son numéro, de type <ttcode>int</ttcode>. Un processus peut aussi s'envoyer un signal à lui-même.

Les fonctions suivantes, fournies par l'en-tête <ttcode><signal.h></ttcode>, sont utilisées dans la gestion des signaux :

* <ttcode>signal()</ttcode> pour définir un gestionnaire de signal;

* et <ttcode>raise()</ttcode> pour envoyer un signal au processus courant.

Le C définit ces deux fonctions, et pas plus, alors que les signaux peuvent faire beaucoup plus... En particulier, aucune fonction pour envoyer un signal à un autre processus n'est définie. Cela est dû au fait que, sur certains systèmes, la notion de processus n'existe pas, et une seule tâche s'exécute. Dans de telles situations, il serait aberrant de demander à un compilateur C pour un tel système de fournir des moyens de communications inter-processus ! Par contre, les communications inter-processus étant chose courante dans de nombreux autres systèmes, des extensions fournissent des moyens de le faire (voir par exemple la fonction <ttcode>kill()</ttcode> définie dans POSIX, cf. le chapitre [[Programmation POSIX:Signaux|Gestion des signaux]] du livre [[Programmation POSIX]]).

permet de définir un gestionnaire de signal. La signature de cette fonction étant un peu complexe, on peut la simplifier en utilisant un <ttcode>typedef</ttcode>:

Ainsi, on voit mieux comment fonctionne cette fonction (notez que le type <ttcode>t_handler</ttcode> n'est pas défini par la norme, et n'est ici que pour clarifier la syntaxe). Elle prend deux paramètres:

Le premier paramètre est le numéro du signal. La norme définit un faible nombre de signaux, par des macros dans l'en-tête <ttcode><signal.h></ttcode>, par exemple <ttcode>SIGSEGV</ttcode> qui indique un accès illégal à la mémoire (''SEGmentation Violation''), et laisse à l'implémentation la liberté de définir d'autres types de signaux.

*<ttcode>SIG_IGN</ttcode> (macro définie dans <ttcode><signal.h></ttcode>): tout signal ayant le numéro <ttcode>sig</ttcode> sera ignoré (i.e. rien ne se passera, le programme continue de s'exécuter);

*<ttcode>SIG_DFL</ttcode> (id.): le gestionnaire de signal par défaut sera mis en place pour ce type de signal.

*un pointeur vers une fonction de type <ttcode>t_handler</ttcode>: cette fonction sera appelée lorsqu'un signal de type <ttcode>sig</ttcode> sera reçu par le processus.

Cette fonction renvoie la valeur du dernier gestionnaire de signal pour le numéro donné (qui peut être <ttcode>SIG_IGN</ttcode> ou <ttcode>SIG_DFL</ttcode>).

En cas d'erreur, la fonction renvoie <ttcode>SIG_ERR</ttcode> et place la variable <ttcode>errno</ttcode> à une valeur significative.

Elles prennent un argument de type <ttcode>int</ttcode>, qui est le numéro du signal, et ne renvoient rien. En effet, ces fonctions étant appelées de manière asynchrone, leur éventuelle valeur de retour ne serait récupérée, et encore utilisée, par personne...

Comme on utilise <ttcode>signal</ttcode> pour associer à chaque numéro de signal une fonction qui va gérer les signaux de ce numéro, on pourrait penser qu'il n'est pas nécessaire de donner ce numéro en paramètre à la fonction. Cependant cela s'avère pratique, car on peut ainsi définir une seule fonction qui peut gérer plusieurs types de signaux, et dont le comportement variera en fonction du signal à traiter.

Voici un exemple simple de définition et de mise en place d'un gestionnaire de signaux, pour le type de signal <ttcode>SIG_FPE</ttcode>, qui concerne des exceptions lors des calculs en virgule flottante (''Floating Point Exception''):