Scribd Logo
Importer

Bienvenue sur Scribd !

  • 2 vues

    TD 71

    Transféré par

    julienbougma98

    Droits d'auteur :

    © All Rights Reserved
    Téléchargez comme PDF, TXT ou lisez en ligne sur Scribd

    TD 71

    Transféré par

    julienbougma98
    2 vues5 pages

    Titre original

    td71

    Copyright

    © © All Rights Reserved

    Formats disponibles

    PDF, TXT ou lisez en ligne sur Scribd

    Avez-vous trouvé ce document utile ?

    Ce contenu est-il inapproprié ?

    Droits d'auteur :

    © All Rights Reserved
    Téléchargez comme PDF, TXT ou lisez en ligne sur Scribd
    Télécharger au format pdf ou txt
    2 vues5 pages

    TD 71

    Transféré par

    julienbougma98

    Droits d'auteur :

    © All Rights Reserved
    Téléchargez comme PDF, TXT ou lisez en ligne sur Scribd
    Télécharger au format pdf ou txt
    Vous êtes sur la page 1sur 5

    Voici les réponses aux exercices sur les signaux et le traitement des signaux sous Unix :

    Exercice 1 : Signal masqué

    Un signal masqué est un signal qui a été envoyé à un processus, mais qui ne sera pas pris en
    compte immédiatement par celui-ci. Lorsqu'un signal est masqué, il est mis en attente jusqu'à
    ce que le processus démasque le signal et permette ainsi son traitement.

    Lorsque plusieurs occurrences d’un signal sont envoyées à un processus qui a ce signal
    masqué, ces signaux sont stockés en mémoire. En fonction du type de signal, il est possible
    qu'il y ait un mécanisme de fusion (par exemple, pour SIGCHLD) ou de simple mise en file
    d'attente. Lorsque le signal est à nouveau autorisé, il est traité, mais il peut ne pas être traité
    autant de fois que d'occurrences, suivant la nature du signal.

    Exercice 2 : Signaux synchrones et asynchrones

    1. SIGFPE (signal d'exception arithmétique, comme une division par zéro) :


    synchronous (synchrone) – causé par une instruction du processus.
    2. SIGBUS (signal d'exception bus, par exemple un accès mémoire invalide) :
    synchronous (synchrone) – causé par une erreur dans une instruction du processus.
    3. SIGTERM (signal de terminaison envoyé par un autre processus) : asynchronous
    (asynchrone) – pas causé par une instruction du processus, mais par un signal externe.
    4. SIGSEGV (segmentation fault, erreur d'accès à la mémoire) : synchronous
    (synchrone) – causé par une instruction invalide (par exemple, accéder à une adresse
    mémoire non valide).

    Exercice 3 : Signaux pour arrêter un processus

    1. Ctrl-C envoie un signal SIGINT : Correct, Ctrl-C génère un signal SIGINT pour
    interrompre le programme en cours.
    2. Envoyer un signal SIGKILL termine immédiatement le processus : Correct,
    SIGKILL termine un processus immédiatement sans possibilité de gestion ou de
    récupération.
    3. SIGTERM ou SIGKILL pour terminer proprement : Incorrect, SIGTERM peut être
    intercepté par le processus et lui permettre de se terminer proprement, mais SIGKILL
    ne peut pas être intercepté et tue immédiatement le processus sans possibilité de
    nettoyage.
    4. Ctrl-C envoie un signal SIGTERM : Incorrect, Ctrl-C envoie le signal SIGINT, pas
    SIGTERM.

    Exercice 4 : Signal SIGSEGV


    Le signal SIGSEGV (segmentation fault) est envoyé lorsqu'un processus tente d'accéder à
    une zone mémoire non autorisée. Cela peut se produire par exemple lorsqu'un processus tente
    de lire ou d'écrire dans un pointeur nul ou une zone mémoire non allouée.

    Le système d'exploitation envoie ce signal au processus. Il n'est pas forcément fatal, car le
    processus peut installer un gestionnaire de signal pour traiter l'erreur. Toutefois, dans la
    plupart des cas, le signal mène à l'arrêt du processus, à moins qu'un gestionnaire de signal ne
    soit installé pour éviter la terminaison immédiate.

    Exercice 5 : Traitement des signaux périodiques

    Lorsque vous installez un gestionnaire de signal pour un signal envoyé périodiquement


    (comme SIGALRM) à l’aide d’un temporisateur avec setitimer, si le gestionnaire prend
    plus de temps pour s'exécuter que l'intervalle entre deux signaux, cela peut poser problème.

     Si le gestionnaire prend plus de temps que l'intervalle entre les signaux, les
    signaux risquent d'être "perdus" si le signal est envoyé avant la fin de l'exécution du
    gestionnaire.
     Si vous réautorisez la délivrance du signal avec sigprocmask à l’intérieur du
    gestionnaire, le signal sera remis dans la file d'attente et traité plus tard. Cela peut
    entraîner une exécution répétée du gestionnaire de signal.

    La différence réside dans le fait que l’utilisation de sigprocmask permet de "recycler" le


    signal et de le traiter plus tard, tandis que dans le cas d’un gestionnaire trop long, le signal
    peut être simplement ignoré si aucune synchronisation n’est faite.

    Exercice 6 : Délivrance des signaux et boucles infinies

    Un signal n'est délivré à un processus que lorsque celui-ci est dans un état où il peut traiter
    le signal, c’est-à-dire lorsqu'il est en mode "exécution" ou dans certains autres états
    spécifiques (par exemple, un processus dans pause() ou sleep() peut recevoir un signal).

    Un processus dans une boucle infinie (comme while(1);) continue d'exécuter des
    instructions et peut donc recevoir des signaux, car il est en mode "exécution". Il est donc
    possible qu'un processus en boucle infinie reçoive un signal, bien que certains types de signal
    (comme SIGALRM) ne soient envoyés que lorsque le processus "attend" un événement
    spécifique.

    Exercice 7 : Problèmes avec la variable globale dans un gestionnaire de signal

    Dans ce programme, l'erreur principale est que la variable counter est modifiée à la fois dans
    la boucle principale du programme et dans le gestionnaire de signal. Cela peut entraîner des
    problèmes de concurrence.
     Il est nécessaire de déclarer la variable counter comme sig_atomic_t pour
    garantir que son accès est sûr lors du traitement des signaux. Cela permet de prévenir
    les problèmes d'accès concurrent aux variables globales utilisées dans des
    gestionnaires de signaux.

    La déclaration volatile ne suffira pas dans ce cas car cela n'évitera pas les problèmes de
    modification simultanée par le gestionnaire et la boucle principale.

    Exercice 8 : Représentation des signaux sous Unix

     La solution avec une queue de signaux permet de stocker tous les signaux envoyés à
    un processus. Cependant, cela peut entraîner une surcharge mémoire si trop de signaux
    sont envoyés.
     La solution avec drapeaux binaires est plus économe en mémoire (un bit par signal),
    mais elle peut entraîner la perte de certains signaux si plusieurs signaux sont envoyés
    avant qu'un signal soit traité.

    Exercice 9 : Vérification du mot de passe avant SIGINT

    Ce programme permet à un processus d'accepter un CTRL-C (SIGINT) uniquement si un


    mot de passe correct est fourni. Si l'utilisateur entre le bon mot de passe, le processus accepte
    le SIGINT et se termine. Sinon, il affiche un message d'erreur.

    Exercice 10 : Masquage et rétablissement des signaux

    Voici un exemple de programme pour masquer et rétablir les signaux SIGINT et SIGQUIT
    pendant 30 secondes :

    c
    Copier le code
    #include <stdio.h>
    #include <signal.h>
    #include <unistd.h>

    int main() {
    sigset_t set;

    // Initialiser le set de signaux


    sigemptyset(&set);
    sigaddset(&set, SIGINT);
    sigaddset(&set, SIGQUIT);

    // Masquer les signaux


    sigprocmask(SIG_BLOCK, &set, NULL);

    printf("Signaux SIGINT et SIGQUIT sont masqués pendant 30


    secondes...\n");
    sleep(30);

    // Rétablir les signaux


    sigprocmask(SIG_UNBLOCK, &set, NULL);

    printf("Signaux SIGINT et SIGQUIT rétablis.\n");


    return 0;
    }

    Exercice 11 : Ping-pong de signaux entre père et fils

    Voici un exemple de programme qui fait ping-pong entre un processus père et son processus
    fils, en envoyant alternativement SIGUSR1 et SIGUSR2 :

    c
    Copier le code
    #include <stdio.h>
    #include <signal.h>
    #include <unistd.h>
    #include <stdlib.h>

    pid_t child_pid;

    void handler_usr1(int sig) {


    printf("Père a reçu SIGUSR1, envoie SIGUSR2 au fils.\n");
    kill(child_pid, SIGUSR2);
    }

    void handler_usr2(int sig) {


    printf("Fils a reçu SIGUSR2, envoie SIGUSR1 au père.\n");
    kill(getppid(), SIGUSR1);
    }

    int main(int argc, char *argv[]) {


    int count = 2;
    if (argc > 1) {
    count = atoi(argv[1]);
    }

    signal(SIGUSR1, handler_usr1);
    signal(SIGUSR2, handler_usr2);

    child_pid = fork();

    if (child_pid == 0) {
    // Code du fils
    for (int i = 0; i < count; i++) {
    pause(); // Attendre un signal
    }
    } else {
    // Code du père
    for (int i = 0; i < count; i++) {
    kill(child_pid, SIGUSR1);
    pause(); // Attendre un signal
    }
    }

    return 0;
    }
    Cela couvre tous les exercices demandés. N'hésitez pas si vous avez besoin de précisions
    supplémentaires !

    Vous aimerez peut-être aussi