Signaux en C

**Raikyn** · 20/04/2013, 10h45

Bonjour,

Je commence à étudier l'utilisation des signaux en C, et j'ai du mal à programmer un récepteur/émetteur.
Récepteur qui doit juste afficher le signal reçu (dès qu'il en reçois un). Et l’émetteur qui prend le pid du processus cible et lui envoi des signaux aleatoire en boucle.

Je n'arrive donc pas à coder ça, je pense quand même comprendre comment ça marche et je sais aussi comment envoyer un signal avec kill, le différent type de signaux. Je me renseigne encore sur le signal handler, mais c'est assez confu pour moi.

Si vous pouviez me donner des indications, je serai ravis !

Merci d'avance.

**Kirilenko** · 20/04/2013, 12h39

Bonjour,

Le mieux est de prendre d'emblée de bonnes habitudes ; éviter signal et y préférer sigaction pour définir des handlers personnalisés, mieux documenté, mieux standardisé, bref, mieux. Pour attraper un certain nombre de signaux, tu peux utiliser un tableau. Exemple avec quatre signaux :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
#include <signal.h>
#include <stddef.h>
 
int sigarray[] =
{
    SIGINT,
    SIGABRT,
    SIGBUS,
    SIGUSR2
};
size_t sigsize = sizeof sigarray / sizeof *sigarray;

On notera qu'on peut les partager entre les fichiers sources de l'émetteur et le récepteur afin de faciliter l'évolution du code. On peut donc très bien les mettre dans un module à part. Un fichier d'en-tête :

Code :

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

1
2
3
4
5
6
7
8
9
#ifndef H_LP_SIGARRAY_20130420121903
#define H_LP_SIGARRAY_20130420121903
 
#include <stddef.h>
 
extern int sigarray[];
extern size_t sigsize;
 
#endif

Et un fichier source :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
#include "sigarray.h"
#include <signal.h>
#include <stddef.h>
 
int sigarray[] =
{
    SIGINT,
    SIGABRT,
    SIGBUS,
    SIGUSR2
};
 
size_t sigsize = sizeof sigarray / sizeof *sigarray;

Il faudra compiler le fichier source en même temps que celui de l'émetteur et du récepteur ; et inclure le fichier d'en-tête dans chacune des unités de traduction susmentionnées.

La suite de l'algorithme consiste à affecter à chaque élément du tableau le même handler :

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
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
 
struct sigaction handler;
size_t i;
 
if (sigfillset(&handler.sa_mask) == -1)
{
    perror("sigfillset");
    return EXIT_FAILURE;
}
 
handler.sa_handler = handle_signals;
handler.sa_flags = 0;
 
for (i = 0; i < sigsize; i++)
{
    if (sigaction(sigarray[i], &handler, NULL) == -1)
    {
        perror("sigaction");
        return EXIT_FAILURE;
    }
}

Enfin, tu peux te mettre en attente d'un signal grâce à la fonction pause :

Code :

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

1
2
3
4
5
6
7
8
9
#include <sys/types.h>
#include <unistd.h>
 
printf("#%d is waiting for signals\n", (int)getpid());
 
for (;;)
{
    (void)pause();
}

Quant à la routine de traitement du signal, il suffit d'y afficher la valeur du paramètre :

Code :

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

1
2
3
4
5
6
7
8
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
 
static void handle_signals(int signum)
{
    (void)printf("#%d: Signal %d received\n", (int)getpid(), signum);
}

Du côté de l'émetteur, tu dois avoir toutes les clés en main pour le faire. Tu peux utiliser les arguments du main pour savoir le PID du processus à considérer comme cible.

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
#include <errno.h>
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
 
long int pid;
 
if (argc < 2)
{
    fprintf(stderr, "Not enough command-line arguments\n");
    return EXIT_FAILURE;
}
 
errno = 0;
pid = strtol(argv[1], NULL, 10);
 
if ((pid == LONG_MIN || pid == LONG_MAX) && errno != 0)
{
    perror("strtol");
    return EXIT_FAILURE;
}

Ensuite, on génère une valeur pseudo-aléatoire (contenant un léger biais, d'ailleurs), à chaque tour de boucle.

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
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
 
srand(time(NULL));
 
for (;;)
{
    int signum = rand() % sigsize;
 
    printf("#%d: Send next signal? ", (int)getpid());
    getchar();
 
    if (kill((pid_t)pid, sigarray[signum]) == -1)
    {
        perror("kill");
        return EXIT_FAILURE;
    }
}

L'ennui, c'est que, pour quitter les deux applications, il faut y aller à coup de signaux, justement. Mais tu peux aisément ajouter une interface par le biais d'entrées/sorties afin de rendre tout cela interactif.

Voilà ce que j'obtiens à la fin (mea culpa si il y a des erreurs, de toute manière ce n'est pas fait pour être copié/collé comme tel) :

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
40
41
42
43
44
45
46
47
/* receiver.c */
 
#include "sigarray.h"
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
 
static void handle_signals(int signum)
{
    printf("#%d: Signal %d received\n", (int)getpid(), signum);
}
 
int main(void)
{
    size_t i;
 
    struct sigaction handler;
 
    if (sigfillset(&handler.sa_mask) == -1)
    {
        perror("sigfillset");
        return EXIT_FAILURE;
    }
 
    handler.sa_handler = handle_signals;
    handler.sa_flags = 0;
 
    for (i = 0; i < sigsize; i++)
    {
        if (sigaction(sigarray[i], &handler, NULL) == -1)
        {
            perror("sigaction");
            return EXIT_FAILURE;
        }
    }
 
    printf("#%d is waiting for signals\n", (int)getpid());
 
    for (;;)
    {
        (void)pause();
    }
 
    return EXIT_SUCCESS;
}

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
40
41
42
43
44
45
46
47
48
49
50
51
/* transmitter.c */
 
#include "sigarray.h"
#include <errno.h>
#include <limits.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
#include <time.h>
 
int main(int argc, char *argv[])
{
    long int pid;
 
    if (argc < 2)
    {
        fprintf(stderr, "Not enough command-line arguments\n");
        return EXIT_FAILURE;
    }
 
    errno = 0;
    pid = strtol(argv[1], NULL, 10);
 
    if ((pid == LONG_MIN || pid == LONG_MAX) && errno != 0)
    {
        perror("strtol");
        return EXIT_FAILURE;
    }
 
    srand(time(NULL));
 
    for (;;)
    {
        int signum = sigarray[rand() % sigsize];
 
        printf("#%d: Send next signal? ", (int)getpid());
        getchar();
 
        if (kill((pid_t)pid, signum) == -1)
        {
            perror("kill");
            return EXIT_FAILURE;
        }
 
        printf("#%d Signal %d sent\n", (int)getpid(), signum);
    }
 
    return EXIT_SUCCESS;
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
/* sigarray.c */
 
#include "sigarray.h"
#include <signal.h>
#include <stddef.h>
 
int sigarray[] =
{
    /* TODO */
};
 
size_t sigsize = sizeof sigarray / sizeof *sigarray;

Code :

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

1
2
3
4
5
6
7
8
9
10
11
/* sigarray.h */
 
#ifndef H_LP_SIGARRAY_20130420121903
#define H_LP_SIGARRAY_20130420121903
 
#include <stddef.h>
 
extern int sigarray[];
extern size_t sigsize;
 
#endif

Bonne journée !

**Raikyn** · 20/04/2013, 12h57

Whao merci ! Je vais prendre le temps de bien comprendre tout ça !

**Obsidian** · 20/04/2013, 15h53

Envoyé par Raikyn

Whao merci ! Je vais prendre le temps de bien comprendre tout ça !

Un gros +1 à Kirilenko pour avoir pris le temps de rédiger tout cela !

Détail important : les signaux UNIX ne servent surtout pas à faire de la transmission de données entre deux processus ! C'est important parce que j'ai vu plusieurs profs faire la confusion (dont un des miens) et qu'on a même vu ici un étudiant tenter de transmettre des infos « en morse » d'un processus à l'autre en les émettant bit à bit et en utilisant SIGUSR1 pour un « zéro » et SIGUSR2 pour un « un ». Il avait fait cela avec beaucoup de sérieux mais se demandait pourquoi c'était si lent.

**Metalman** · 20/04/2013, 19h47

C'est un projet dans une certaine école le chat avec les deux signaux...
Ca sert justement à montrer tout ce qu'il est possible de faire avec les interfaces systèmes, même si elles ne sont pas exactement faites pour cela ! xD
...et surtout apprendre à émettre et receptioner des signaux !

**Obsidian** · 20/04/2013, 22h59

Envoyé par Metalman

C'est un projet dans une certaine école le chat avec les deux signaux... Ca sert justement à montrer tout ce qu'il est possible de faire avec les interfaces systèmes, même si elles ne sont pas exactement faites pour cela ! xD

C'était effectivement un projet scolaire mais je ne m'étais pas rendu compte que c'était le thème même de l'exercice :-\ Je suppose (au vu du smiley) que ton commentaire était ironique mais là, ce serait plutôt « montrer tout ce qu'il ne faut pas faire ». Dans une école, à moins que ce soit justement expliqué comme tel, c'est plutôt une mauvaise chose.

**Metalman** · 21/04/2013, 00h54

Je n'ai pas fait celle où ce sujet est donné (j'ai plutôt fait sa "grande soeur" qui partage les locaux), mais mes contacts là bas m'en ont parlé, et le sujet est justement de tout faire à base de signaux si je ne me trompe pas... afin de savoir bien les gérer, travailler les chaînes de caractères, l'encodage/décodage binaire des caractères, et la récupération des PID...
C'est une IPC peu commune, mais pas impossible à utiliser.

**Obsidian** · 21/04/2013, 16h04

Envoyé par Metalman

afin de savoir bien les gérer, travailler les chaînes de caractères, l'encodage/décodage binaire des caractères, et la récupération des PID...

Je ne vois pas le rapport entre les signaux UNIX et les chaînes de caractères.

Plus précisément, tous les thèmes que tu cites sont à voir et il est intéressant de les regrouper dans un petit projet qui implique le tout, mais j'aurais placé les signaux à part ou, à tout le moins, je les aurais fait traiter un cas simple, comme afficher un message à réception de SIGUSR1, ou alors réellement utile comme le traitement d'un processus fils mort à réception de SIGCHLD.

C'est une IPC peu commune, mais pas impossible à utiliser.

C'est bien ça le problème : les signaux sont classés dans les IPC parce qu'ils comptent au nombre des rares mécanismes qui permettent à un processus d'influer sur un autre, mais ils ne sont absolument pas faits pour échanger des données.

Même pour l'exercice, et j'ai envie de dire — surtout pour l'exercice — il ne faut pas montrer à faire ce genre d'hérésie puisqu'au contraire, il faut insister sur le fait que ce n'est pas du tout un canal de transmission. Faire faire ce genre d'exercice, c'est justement montrer qu'on n'a pas compris de quoi il s'agit.

Un signal, c'est relativement « violent » : c'est un mécanisme système comparable dans la forme aux interruptions logicielles et matérielles (IRQ). Ça préempte ton processus à n'importe quel endroit, ça engendre un overhead très important et flooder un processus de signaux, parce que c'est bien de cela qu'il s'agit, peut mettre à mal les performances du système entier. C'est également « dangereux » dans le sens où un signal non intercepté provoque la mort du processus à quelques rares exceptions, et ce n'est pas un hasard.

Les signaux UNIX servent principalement à indiquer un événement exceptionnel qui :

Dépend du système ;
Est extérieur au processus ;
Engendre une situation qui empêche le processus en question de continuer à se dérouler normalement.

Ça peut être typiquement un tube brisé, parce que l'homologue l'a refermé (ou s'est refermé) prématurément, une demande explicite d'interruption, l'extinction totale du système ou une demande de prise en charge prioritaire d'une donnée arrivant sur un périphérique doté de peu de mémoire avec SIGURG. C'est aussi pour cela que les différents signaux existants sont peu nombreux et qu'on ne peut pas créer les siens.

A contrario, les signaux ne sont absolument pas bufferisés : un signal « déclenché » le reste jusqu'à ce qu'il soit pris en charge, comme une IRQ, et ce même s'il est temporairement masqué. Par contre, tous les autres signaux similaires arrivant derrière sont perdus puisqu'ils ne font que marquer le même signal comme « en attente de traitement » (pending). C'est un peu comme quand tu appelles l'ascenseur : appuyer sur le bouton le fait descendre, appuyer plusieurs fois de suite ne sert à rien : ça n'annule pas l'appel en cours, ça ne fait pas revenir n fois l'ascenseur au même étage et ça ne le fait pas descendre plus vite non plus.

Ça veut donc dire, dans cet exercice, que quand tu reçois un signal SIGURG1 ou SIGURG2, tu ne peux pas savoir si tu as reçu 1 ou plusieurs bits de la même valeur, ni combien. En outre, si le scheduler ne passe pas immédiatement la main au processus cible quand tu appelles kill, l'émetteur a le temps d'envoyer à la fois SIGUSR1 et SIGUSR2, et tu ne sais donc plus dans quel ordre tu as reçu tes 1 et tes 0.

Le seul moyen que tu as de t'en sortir est alors de renvoyer un signal servant d'accusé de réception pour chaque bit reçu à l'émetteur ! Donc, tu doubles encore le nombres de signaux échangés, ta consommation processeur s'envole, etc. et tout cela en espérant que l'utilisateur n'ait pas lui-même la bonne idée d'envoyer un signal aux processus avec la commande « kill », ce qui suffirait à corrompre l'échange.

Bref, ça peut être marrant dans le cadre du « gruik contest » mais dans une école, quand on sait à quel point la programmation est chronophage et combien les étudiants en bavent, au départ, avec des trucs élémentaires tels que les pointeurs, je ne vois vraiment pas ce qu'il peut rester de bénéfique dans un tel devoir.

**Metalman** · 21/04/2013, 16h17

Moi je n'en pense rien...
Le sujet est comme ça depuis longtemps, et ça n'est qu'un des très nombreux projets qu'ils ont... c'est à eux de le réussir ainsi...

Et je pense qu'ils sont assez malins pour voir que c'est très lent, et qu'il y a de la perte justement...
Ca les force du coup à réfléchir et s'intéresser sur l'intégralité du fonctionnement des signaux, ses limitations et possibilités.

Au final : comme tu l'as toi-même expliqué... ils en apprennent beaucoup en s'en servant dans des conditions extrêmes et pas du tout adaptées... ce qui est un des buts.

**imperio** · 22/04/2013, 08h36

Envoyé par Metalman

Moi je n'en pense rien...
Le sujet est comme ça depuis longtemps, et ça n'est qu'un des très nombreux projets qu'ils ont... c'est à eux de le réussir ainsi...

Et je pense qu'ils sont assez malins pour voir que c'est très lent, et qu'il y a de la perte justement...
Ca les force du coup à réfléchir et s'intéresser sur l'intégralité du fonctionnement des signaux, ses limitations et possibilités.

Au final : comme tu l'as toi-même expliqué... ils en apprennent beaucoup en s'en servant dans des conditions extrêmes et pas du tout adaptées... ce qui est un des buts.

Ce qui fait qu'il y a de la perte est un manque d'optimisation côté client. Tous les signaux envoyés sont reçus mais n'ont pas forcément le temps d'être traités.

Cet exercice avait surtout pour but de nous apprendre les signaux afin de nous préparer aux projets qui suivaient. Exemple : recoder un shell, pour la gestion des processus fils mort, appel a SIGQUIT ou SIGTSTP... L'année suivante pour le recode de la commande script.

Au vu des performances, il paraît de toute façon évident qu'il vaut mieux passer par d'autres méthodes pour communiquer entre des processus (pipe, socket...).

**Obsidian** · 22/04/2013, 19h56

Envoyé par imperio

Ce qui fait qu'il y a de la perte est un manque d'optimisation côté client. Tous les signaux envoyés sont reçus mais n'ont pas forcément le temps d'être traités.

Non, justement (et c'est important) : ce n'est pas dû à un « manque d'optimisation côté client ». Un signal doit rester exceptionnel. Disons qu'à la louche, si tu as besoin d'envoyer plus d'un signal par seconde, ton programme est mal conçu. Les signaux ne sont pas « un moyen de communication parmi d'autres ».

Cet exercice avait surtout pour but de nous apprendre les signaux afin de nous préparer aux projets qui suivaient. Exemple : recoder un shell, pour la gestion des processus fils mort, appel a SIGQUIT ou SIGTSTP... L'année suivante pour le recode de la commande script. Au vu des performances, il paraît de toute façon évident qu'il vaut mieux passer par d'autres méthodes pour communiquer entre des processus (pipe, socket...).

Comme on l'a dit jusqu'ici, ce n'est pas une simple question de « performances ». C'est pour cela que j'insiste et que, justement, je trouve l'exercice plus dangereux que profitable.

Je saisis très bien la philosophie de la chose : aller utiliser un outil dans un contexte complètement inhabituel, juste une fois et pour l'exercice. Mais ça ne se fait qu'une fois qu'on maîtrise déjà l'outil en question et quand il n'y a rien de plus important à voir d'abord. Mais envoyer des bits à 0 ou à 1 avec SIGUSR1 et SIGUSR2, c'est montrer aux gens ce qu'il ne faut précisément PAS faire avec les signaux. Ça aurait au moins eu un sens si c'était dans ce sens-là qu'on vous avait présenté l'exercice.

**Damdoshi** · 22/04/2013, 22h06

Il s'agit pour le coup de l'un des projets les plus réussis (C'est pas vraiment compliqué, faut dire...), et les signaux l'une des notions d'Unix la plus maitrisée par les étudiants de nos écoles respectives. Et je parle bien sur d'une utilisation normale de ces outils.

La dangerosité de l'exercice est fort discutable. C'est sans risque que nous parions sur l'intelligence des étudiants, pour le coup.

Par ce procedé, nous les initions aussi aux principes fondamentaux de la communication série, par ailleurs. Meme si assez peu d'entre eux remarquent la similitude.

Après, je comprends qu'il faille éviter de faire croire à ceux qui liraient ce post un peu rapidement que cela sert à ca.

Signaux en C

C

Discussions similaires

Partager

Partager