TP 5 - Signaux

• lab05-refcard.pdf

• Génération de signaux
• Soumission et recevoir des signaux
• Types standard de signaux
• Les messages décrivant des signaux
• Masques de signalisation. Verrouillage du signal
• Traitement du signal
• Rapport de processus
• En attente d'un signal
• Timers sous Linux

Dans le monde réel, un processus peut découvrir une variété de contingences qui affectent le flux normal de l'exécution. Si le processus ne peut pas gérer, ils sont passés plus loin, le système d'exploitation. Quel système d'exploitation ne sait pas si le processus peut continuer à exécuter normalement sans effets secondaires indésirables est nécessaire pour terminer le processus de force. Une solution à ce problème est les signaux.

• En règle générale l'action par défaut est processus d'achèvement.

• Si un processus veut ignorer un signal, le système d'exploitation ne sera pas envoyer ce processus de signal.

• Si un processus spécifique qui veut signal de bloc, le système d'exploitation ne sera plus envoyer des signaux à traiter ce type en question, mais enregistrera seulement le premier signal de ce type, le reste est perdu. Lorsque le processus décide qu'il veut recevoir des signaux à nouveau de ce type, en cas de signal en attente, il sera envoyé.

L'ensemble de ces signaux est terminé; OS conserve pour chaque processus, une table des actions choisie pour chaque type de signal. A chaque fois que ces actions sont bien définies. Lors du démarrage de la table de processus est initialisé avec l'action par défaut. Le signal de traitement est déterminé par le processus de réception du signal, mais est choisi automatiquement de la table. Les signaux sont flux d'exécution synchrone / asynchrone du processus qui reçoit le signal si l'événement provoquant le signal d'envoi est exécution synchrone / asynchrone des flux de processus.

• Un événement est flux synchrone de l'exécution du processus qui se produit chaque fois que le programme en cours d'exécution au même point dans le flot d'exécution. Des exemples tentent d'accéder à un emplacement mémoire invalide ou permis, division par zéro, etc.

• Un événement est asynchrone si il est pas synchronisé. Des exemples d'événements asynchrones: un signal envoyé par un autre processus (terminaison de signal d'un processus enfant), ou une demande de terminaison externe (utilisateur veut réinitialiser l'ordinateur).

Un signal reçu par un processus peut être généré:

• Soit directement système d'exploitation - où il signale diverses erreurs;

• ou un processus - qui peut également envoyer ses propres signaux (le signal passera également par le système d'exploitation).

Dans certains cas, il faut savoir, sûrement, qui a envoyé un signal pour atteindre sa destination et donc, le processus lui répondre (faire une des actions possibles). Le système d'exploitation fournit un autre moyen d'envoyer un signal, qui garantit si le signal a atteint sa destination, si cette action a échoué. Ceci est accompli en créant une pile de signaux d'une certaine capacité (il doit être fini, ne pas provoquer des situations de débordement). Envoi d'un signal, le système d'exploitation vérifie si la pile est pleine. Dans ce cas, l'application échoue, l'autre signal est placé sur la pile et l'opération se termine avec succès.

Le signal terme est utilisé pour indiquer alternativement être une sorte d'objets ou réels signaux de ce type.

En général, les événements générant des signaux se répartissent en trois catégories principales:

• Une “erreur” indique qu'un programme a effectué une opération non autorisée et ne peut pas continuer son exécution. Cependant, tous les types d'erreur ne génèrent pas de signaux (en fait, la plupart ne le font pas). Par exemple, ouvrir un fichier inexistant est une erreur, mais cela ne génère pas de signal. Au lieu de cela, l'appel système ouvert renvoie -1 indiquant que l'appel s'est terminé avec une erreur. Généralement, les erreurs associées à certaines bibliothèques sont signalées en renvoyant une valeur spéciale. Les erreurs qui génèrent des signaux sont celles qui peuvent apparaître n'importe où dans le programme, pas seulement dans les appels des bibliothèques. Ils incluent la remise à zéro et l'accès invalide à la mémoire.

• Un “événement externe” est généralement lié aux E / S et à d'autres processus. Exemples: nouvelle entrée de données, expiration du temporisateur, achèvement d'un processus enfant.

• La demande explicite indique l'utilisation d'un appel système, tel que kill, pour générer un signal.

Les signaux peuvent être synchrones ou asynchrones:

• Un signal “synchrone” fait référence à une action spécifique du programme et est envoyé (s'il n'est pas bloqué) au cours de cette action. La plupart des erreurs génèrent des signaux synchrones. Les signaux peuvent également être générés de manière synchrone et par des demandes explicites envoyées par un processus lui-même. Sur certains ordinateurs, certains types d’erreurs matérielles (généralement des exceptions en virgule flottante) ne sont pas signalés comme étant complètement synchroniques et ils peuvent obtenir certaines instructions ultérieurement.

• Les signaux asynchrones sont générés par des événements incontrôlables par le processus qui les reçoit. Ces signaux arrivent à des moments imprévisibles. Les événements externes génèrent des signaux asynchrones, ainsi que des demandes explicites envoyées par d'autres processus.

Un type de signal donné est synchrone ou asynchrone. Par exemple, les signaux d'erreur sont généralement synchrones car les erreurs génèrent des signaux synchrones. Cependant, tout type de signal peut être généré de manière synchrone ou asynchrone avec une demande explicite.

Lorsqu'un signal est généré, il entre dans un état en attente. Normalement, il reste dans cet état pendant très peu de temps et est ensuite envoyé au processus de destination. Toutefois, si ce type de signal est actuellement bloqué, il peut rester à l'état indéfini jusqu'à ce que les signaux de ce type soient déverrouillés. Une fois que ce type de signal est déverrouillé, il sera envoyé immédiatement. Lorsque le signal a été reçu, immédiatement ou avec retard, l'action spécifiée pour ce signal est exécutée. Pour certains signaux, tels que «SIGKILL» et «SIGSTOP», l'action est fixée (le processus est terminé), mais pour la plupart des signaux, le programme peut choisir de:

• ignorer le signal
• Spécifie une fonction gestionnaire
• accepte l'action par défaut pour ce type de signal.

Le programme spécifie votre choix en utilisant des fonctionnalités telles que signal ou sigaction . Lorsque le gestionnaire est en cours d'exécution, ce type de signal est normalement verrouillé (le déverrouillage sera effectué par une demande explicite du gestionnaire qui gère le signal).

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
 
pid_t child1, child2;
int child1_pid;
 
 
void signal_handler(int signum)
{
 
    switch(signum) {
        case SIGINT:
            printf("CTRL+C received in %d Exiting\n", getpid());
            exit(EXIT_SUCCESS);
        case SIGUSR1:
            printf("SIGUSR1 received. Continuing execution\n");
    }
}
 
int main(void)
{
 
    printf("Process %d started\n", getpid());
 
    /* Semnale ca SIGKILL sau SIGSTOP nu pot fi prinse */
    if (signal(SIGKILL, signal_handler) == SIG_ERR)
        printf("\nYou shall not catch SIGKILL\n");
 
    if(signal(SIGINT, signal_handler) == SIG_ERR) {
        printf("Unable to catch SIGINT");
        exit(EXIT_FAILURE);
    }
 
    if(signal(SIGUSR1, signal_handler) == SIG_ERR) {
        printf("Unable to catch SIGUSR1");
        exit(EXIT_FAILURE);
    }
 
 
    printf("Press CTRL+C to stop us\n");
 
    while(1) {
        sleep(1);
    }
 
    return 0;
}

Si l'action spécifiée pour un type de signal est de ignorer , alors tout signal de ce type généré pour le processus en question est ignoré. La même chose se produit si le signal est bloqué à ce moment-là. Un signal négligé dans ce mode ne sera jamais reçu, ou si le programme spécifie ensuite une action différente pour ce type de signal, puis le déverrouille. Si un signal est reçu pour lequel aucun type d'action n'a été spécifié, l'action par défaut est exécutée. Chaque type de signal a sa propre action par défaut. Pour la plupart des signaux, l'action par défaut est mettant fin au processus . Pour certains types de signaux, qui sont des événements sans conséquences majeures, l'action par défaut consiste à ne rien faire.

Lorsqu'un signal force un processus à se terminer, le processus parent peut déterminer la cause de la terminaison en examinant le code de terminaison signalé par les fonctions 'wait' et 'waitpid'. Les informations pouvant être obtenues incluent le fait que le processus s'est terminé par un signal ainsi que le type de signal. Si un programme que vous exécutez à partir de la ligne de commande est terminé par un signal, le shell affiche généralement des messages d'erreur. Les signaux qui représentent normalement des erreurs de programme ont une propriété spéciale: lorsqu'un de ces signaux termine le processus, il écrit également un fichier core dump qui enregistre le statut du processus à la fin. Vous pouvez examiner le fichier avec un débogueur pour déterminer la cause de l'erreur. Si vous générez un signal, qui est une erreur de programme, par une requête explicite et que le processus se termine, le fichier est généré comme si le signal avait été généré par une erreur.