This is an old revision of the document!
Le tuyau est un mécanisme de communication à sens unique entre deux processus. Dans la plupart des implémentations UNIX, un canal apparaît sous la forme d'un espace mémoire d'une certaine taille dans l'espace du noyau. Les processus qui communiquent via un tuyau anonyme doivent avoir un degré de parenté; généralement, un processus qui crée un tuyau appelle ensuite fork et le tuyau est utilisé pour la communication parent-fils. Dans tous les cas, les processus qui communiquent via des canaux anonymes ne peuvent pas être créés par différents utilisateurs du système.
L'appel système à créer est pipe:
int pipe(int filedes[2]);
Le vecteur filedesktop contient deux descripteurs de fichier après l'exécution de la fonction:
filedes [0]
, ouvert à la lecture; filedes [1]
, ouvert à l'écriture;
/ * On considère que le résultat de filedes [1]
est une entrée pour filedes [0]
. * /
Mnemotechnics : STDIN_FILENO
vaut 0 (lecture), STDOUT_FILENO
vaut 1 (écriture).
Note :
PIPE_BUF
1) octets.La plupart des applications de pipeline se ferment à chaque extrémité du tuyau de traitement non utilisées dans la communication unidirectionnelle. Si l'un des descripteurs est fermé, les règles suivantes s'appliquent:
errno
a la valeur EPIPE
.
Élimine le besoin de relation entre les processus qui communiquent. Ainsi, chaque processus peut s'ouvrir pour lire ou écrire le fichier de nom de canal (FIFO), un type de fichier spécial qui conserve les caractéristiques d'un canal. La communication est faite dans un sens ou les deux. Les fichiers FIFO peuvent être identifiés par la lettre p
dans le premier champ de droits d'accès ( ls -l
).
L'appel de bibliothèque pour créer des canaux FIFO est mkfifo:
int mkfifo(const char *pathname, mode_t mode);
Une fois le tube FIFO créé, il peut être utilisé pour toutes les opérations sur les fichiers courants: ouvert
, fermer
, 'lire' ',' écrire '.
Le comportement d'un tuyau FIFO après ouverture est affecté par l'indicateur O_NONBLOCK
:
Lors de la fermeture du dernier fichier descripteur d'écriture pour une FIFO, un “fin de fichier” - “EOF” est généré - pour le processus qui lit à partir de la FIFO.
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.
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 signal reçu par un processus peut être généré:
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:
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 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:
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).
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.
signal
et alors l'opération échouera (avec “errno” sur “EINTR”) ou l'opération sera redémarrée. Les systèmes System V se comportent comme dans le premier cas, BSD comme dans le second. Depuis la glibc v2, le comportement est le même que sous BSD, tout dépend de la définition de _BSD_SOURCE mackerel. Le comportement peut être contrôlé par le programmeur en utilisant sigaction
avec l'indicateur SA_RESTART
.
Cette section répertorie les noms de différents types de signaux standard et décrit le type d’événements qu’il indique.
$ kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 31) SIGSYS 33) SIGRTMIN 34) SIGRTMIN+1 35) SIGRTMIN+2 36) SIGRTMIN+3 37) SIGRTMIN+4 38) SIGRTMIN+5 39) SIGRTMIN+6 40) SIGRTMIN+7 41) SIGRTMIN+8 42) SIGRTMIN+9 43) SIGRTMIN+10 44) SIGRTMIN+11 45) SIGRTMIN+12 46) SIGRTMIN+13 47) SIGRTMIN+14 48) SIGRTMIN+15 49) SIGRTMAX-15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1 64) SIGRTMAX
Les noms des signaux sont définis dans l'en-tête signal.h
. Généralement, les signaux ont des rôles prédéfinis, mais ils peuvent être écrasés par le programmeur.
Les plus communs sont les signaux suivants:
SIGINT
- transmis au toucher de la combinaison CTRL + C
; SIGQUIT
- transmis en appuyant sur la combinaison de touches CTRL + \
; SIGSEGV
- transmis lors de l'accès à un emplacement mémoire invalide, etc. SIGKILL
- ne peut être ignoré ni écrasé. La transmission de ce signal a pour effet de mettre fin au processus, quel que soit le contexte.Le meilleur moyen d’afficher une description d’un signal est d’utiliser le strsignal et le psignal. Ces fonctions utilisent un numéro de signal pour spécifier le type de signal à décrire. Vous trouverez ci-dessous un exemple d'utilisation de ces fonctionnalités:
#include <stdio.h> #include <stdlib.h> #define __USE_GNU #include <string.h> #include <signal.h> int main(void) { char *sig_p = strsignal(SIGKILL); printf("signal %d is %s\n", SIGKILL, sig_p); psignal(SIGKILL, "death and decay"); return 0; }
Pour compiler et exécuter la séquence, procédez comme suit:
so@spook$ gcc -Wall -g -o msg_signal msg_signal.c so@spook$ ./msg_signal signal 9 is Killed death and decay: Killed
Afin de pouvoir effectuer des opérations de blocage / déblocage de signal, nous devons connaître l'état de chaque signal à chaque étape du flux d'exécution. Le système d’exploitation a également besoin de la même chose pour décider du signal à envoyer à un processus (il a besoin de ce type d’informations séparément pour chaque processus). À cette fin, un masque de signaux est utilisé pour chaque processus.
int sigprocmask(int how, const sigset_t *set, sigset_t *oldset);
Le type de données utilisé par les systèmes UNIX pour représenter les masques de signaux est sigset_t
. Les variables de ce type sont 'non initialisées' . Les opérations sur ce type de données sont:
Les fonctions suivantes permettent de manipuler le masque de bits. Ils ne décident pas de l'action de bloquer ou de déverrouiller un signal, mais placent simplement le signal dans le masque binaire (ajoutez le bit correspondant au signal à 1 et supprimez-le à 0), puis utilisez sigprocmask
pour définir l’action de verrouillage / déverrouillage effectif. Vous pouvez trouver plus de détails sur ces fonctionnalités aici.
int sigemptyset(sigset_t *set); int sigfillset(sigset_t *set); int sigaddset(sigset_t *set, int signo); int sigdelset(sigset_t *set, int signo); int sigismember(sigset_t *set, int signo);
gemptset
ou sigfillset
. Le comportement n'est pas défini autrement.
sigset_t set; sigemptyset(&set); sigaddset(&set, SIGINT); while (1) { sleep(5); sigprocmask(SIG_BLOCK, &set, NULL); sleep(5); sigprocmask(SIG_UNBLOCK, &set, NULL); }
Une autre valeur que le premier paramètre de sigprocmask peut prendre est le SIG_SETMASK
, qui spécifie clairement simplement que l'ancien masque (le troisième paramètre) est remplacé par le deuxième paramètre (le nouveau masque). Un exemple d'utilisation est disponible à l'adresse https://support.sas.com/documentation/onlinedoc/sasc/doc750/html/lr1/zlocking.htm "cette adresse.
Le traitement des signaux se fait en associant une fonction ( gestionnaire ) à un signal. La fonction sera appelée lorsque le processus recevra le signal. Traditionnellement, la fonction utilisée pour associer les gestionnaires pour traiter un signal était signal. Pour remédier aux faiblesses de cette fonctionnalité, le standard POSIX a défini la fonction sigaction pour associer un gestionnaire à un signal. La “sigaction” offre plus de contrôle au prix d'un degré de complexité plus élevé.
int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);
Le composant important de la fonction sigaction
est la structure du même nom, décrite dans la page de la fonction manuelle:
struct sigaction { void (*sa_handler)(int); void (*sa_sigaction)(int, siginfo_t *, void *); sigset_t sa_mask; int sa_flags; };
Si le champ sa_flags spécifie l'indicateur SA_SIGINFO
, le gestionnaire utilisé est celui spécifié par sa_sigaction
. Sinon, le gestionnaire utilisé est sa_handler
. Le masque des signaux qui doivent être bloqués lors de l'exécution du gestionnaire est représenté par sa_mask
.
Un exemple d'association d'un gestionnaire de signal est présenté ci-dessous:
#include <signal.h> ... /* SIGUSR2 handler */ static void usr2_handler(int signum) { /* actions that should be taken when the signal signum is received */ ... } int main(void) { struct sigaction sa; memset(&sa, 0, sizeof(sa)); sa.sa_flags = SA_RESETHAND; /* restore handler to previous state */ sa.sa_handler = usr2_handler; sigaction(SIGUSR2, &sa, NULL); return 0; }
SIG_IGN
pour ignorer le signal ou SIG_DFL
pour exécuter l'action par défaut (mettre fin au processus, ignorer le signal, etc.).
Pour transmettre un signal, vous pouvez utiliser le kill ou le sigqueue. Le kill présente le désavantage de ne pas garantir le signal reçu par le processus de destination. S'il est nécessaire d'envoyer un signal à un processus et de savoir avec certitude qu'il est recommandé d'utiliser la fonction sigqueue:
int sigqueue(pid_t pid, int signo, const union sigval value);
La fonction envoie le signal signo
avec les paramètres spécifiés par valeur
au processus avec l'identifiant 'pid'. Si le signal est égal à zéro, les erreurs éventuelles sont vérifiées, mais aucun signal n'est envoyé. Le signal null peut être utilisé pour vérifier que le pid est valide.
La valeur pouvant être envoyée avec le signal est une union:
union sigval { int sival_int; void *sival_ptr; };
Un paramètre envoyé ici apparaît dans la si_value
de la structure siginfo_t
, reçue par le gestionnaire de signaux. Évidemment, n’a aucun sens de transmettre des pointeurs d’un processus à un autre.
Les conditions requises pour qu'un processus soit autorisé à envoyer un signal à un autre processus sont les mêmes que dans le cas d'une suppression. Si le signal spécifié est bloqué à ce moment-là, la fonction quittera immédiatement et si l'indicateur SA_SIGINFO
est défini et qu'il y a des ressources nécessaires, le signal sera mis en file d'attente à l'état en attente (un processus peut avoir un maximum de 'SIGQUEUE_MAX' des signaux). De plus, lorsque le signal est reçu, le champ si_code
, transmis à la structure siginfo
, sera défini sur SI_QUEUE
, et and_value
sur valeur
.
Si le drapeau SA_SIGINFO
n'est pas défini, alors signo
, mais pas nécessairement 'valeur', sera envoyé au moins une fois au processus qui devrait recevoir le signal.
La meilleure solution pour attendre un signal peut être faite en utilisant sigsuspend:
int sigsuspend(const sigset_t *set);
La fonction remplace le masque de signal de processus verrouillé par un ensemble et suspend le processus jusqu'à la réception d'un signal qui n'est pas bloqué par le nouveau masque. A la sortie, la fonction restaure l'ancien masque de signalisation.
Dans la séquence ci-dessous, sigsuspend est utilisé pour suspendre le processus en cours jusqu'à sa réception. signal SIGINT
. Les signaux SIGKILL et SIGSTOP
, bien que présents dans le masque de signal, ne seront pas bloqués:
sigset_t set; /* block all signals except SIGINT */ sigfillset(&set); sigdelset(&set, SIGINT); /* wait for SIGINT */ sigsuspend(&set);
Sous Linux, l'utilisation de minuteries est liée à l'utilisation de signaux. Cela se produit car la plupart des fonctions de la minuterie utilisent des signaux.
Un timer est généralement un ensemble dont la valeur est décrémentée dans le temps. Lorsque le tout atteint 0, la minuterie expire. Sous Linux, l’expiration du minuteur entraîne généralement la transmission d’un signal. Définir un “gestionnaire de minuterie” (routine appelée lorsque la minuterie expire) équivaut donc à définir un gestionnaire pour le signal associé.
Enregistrer un minuteur sous Linux signifie spécifier un intervalle de temps après lequel un minuteur expire et configurer le gestionnaire pour qu'il s'exécute. La configuration du gestionnaire peut être réalisée au moyen de la fonction “sigaction” (à l'expiration du délai imparti, un signal est généré, lequel génère à son tour l'exécution du gestionnaire associé) ou directement via les paramètres du [ http://www.kernel.org/doc/man-pages/online/pages/man2/timer_create.2.html|timer_create]]. L'utilisation d'une minuterie implique plusieurs étapes:
int timer_create(clockid_t clockid, struct sigevent *evp, timer_t *timerid)
Le timer créé est identifié par timerid
. Grâce à la structure 'sigevent', vous définissez la manière dont le minuteur interagira avec le processus / thread qu'il a lancé. Exemple d'utilisation:
timer_t timerid; struct sigevent sev; sev.sigev_notify = SIGEV_SIGNAL; /* notification method */ sev.sigev_signo = SIGRTMIN; /* Timer expiration signal */ sev.sigev_value.sival_ptr = &timerid; timer_create(CLOCK_REALTIME, &sev, &timerid);
Le premier argument peut mesurer le temps réel du système, le temps d'exécution du processus ou le temps d'exécution du processus dans l'espace utilisateur et l'espace noyau. À l'expiration du délai, le minuteur transmettra le signal enregistré à sev.sigev_signo
.
int timer_settime(timer_t timerid, int flags, const struct itimerspec *new_value, struct itimerspec * old_value);
Le renforcement du minuteur implique de compléter la structure itimerspec en spécifiant l'heure de début du minuteur et l'intervalle d'expiration du délai d'attente (les plages sont mesurées en secondes et en nanosecondes). Exemple d'utilisation:
its.it_value.tv_sec = freq_nanosecs / 1000000000; /* Initial expiration in secs*/ its.it_value.tv_nsec = freq_nanosecs % 1000000000;/* Initial expiration in nsecs*/ its.it_interval.tv_sec = its.it_value.tv_sec; /* Timer interval in secs */ its.it_interval.tv_nsec = its.it_value.tv_nsec; /* Timer interval in nanosecs */ timer_settime(timerid, 0, &its, NULL);
int timer_delete(timer_t timerid);
-lrt
Pour résoudre le labo, veuillez cloner repository. si vous en avez déjà un, lancez svp git pull
.
utils.h
avec des fonctions utiles dans le répertoire utils
de l'archive.
sa_flags
de struct sigaction
sur 0
.
Allez dans le répertoire 1-pipe
, vous avez deux programmes: pipe
et reader
.
Dans le fichier pipe.c
, créez un tuyau puis créez un fork. Dans le processus parent, fermez la fin de lecture du tuyau
et écrivez les données dans buffer dans le tube.
Dans le processus enfant, fermez l'écriture du canal, lisez les données de la mémoire tampon dans la mémoire tampon et affichez-les à l'écran.
Suivez les lignes TODO 1.
Dans le fichier reader.c
, lisez le texte stocké dans la variable buffer et affichez-la.
Dans le fichier pipe.c
, modifiez le processus enfant afin qu'après la fermeture de l'extrémité du tuyau,
redirige stdin vers la fin de la lecture du tube et exécute (en utilisant l'une des fonctions exec )
le programme lecteur
.
Regardez TODO 2 pendant des mois.
Allez dans le dossier 2-hitme /
et analysez le contenu du fichier hitme.c. Compiler et exécuter le programme.
Utilisez la commande kill -l
pour lister tous les signaux disponibles. Quelle est la valeur du signal SIGKILL?
Dans une autre console, envoyez le programme hitme avec des signaux compris entre 20 et 25 comme suit:
kill -20 $(pidof hitme) kill -21 $(pidof hitme) kill -22 $(pidof hitme) kill -23 $(pidof hitme) kill -24 $(pidof hitme) kill -25 $(pidof hitme)
Essayez d’envoyer deux fois le même signal et d’expliquer le comportement.
signaux.sa_flags
.
SA_RESETHAND
ne rétablira plus le gestionnaire à la valeur par défaut après la réception du premier signal.
Suivez le commentaire TODO 2
et les autres index que vous trouvez dans le code pour provoquer un accès invalide à la mémoire.
Si vous êtes curieux de savoir ce qui se passe en détail, vous pouvez consulter laboratoire de mémoire virtuelle.
Allez dans le répertoire 3-signaux
et regardez le contenu du fichier signaux.c
. Le programme compte le nombre d'appels du gestionnaire de signaux en cas d'envoi de signaux SIGINT
et SIGRTMIN
Démarrez le programme “signaux”:
./ signaux
dans une console
Pour le cas de signaux “normaux”, dans une autre console, exécutez le script “send_normal.sh”:
./ send_normal.sh
Pour les signaux en temps réel, dans une autre console, exécutez le script send_rt.sh:
./ send_rt.sh
Pour fermer l'exécutable signaux
, le signal SIGQUIT est envoyé. Où se situe la différence?
Lisez la section “Man 7 Signal” de la section “Signaux en temps réel” et passez en revue la section Types de signaux standard.
Allez dans le répertoire 4-askexit
et regardez le code source. Le programme est occupé à attendre, en affichant des numéros consécutifs sur la console.
Vous devez terminer le programme pour intercepter les signaux générés par CTRL + \
, CTRL + C
et SIGUSR1
(utilisez la commande 'kill'). Le gestionnaire associé à chacun des signaux sera “ask_handler”. Pour chaque signal reçu, il sera demandé à l'utilisateur s'il souhaite ou non arrêter l'exécution.
Testez la fonctionnalité du programme.
printf
, scanf
dans le traitement du signal peut être problématique, car ces fonctions ne sont pas sécurisées.
Entrez le répertoire “5-nohup” et créez un programme appelé “mynohup” qui simule la commande nohup. Le programme reçoit, en tant que premier paramètre, le nom d'une commande à exécuter. Le reste des paramètres sont les arguments pour appeler la commande; la liste des arguments peut être nulle.
Le programme exécuté par mynohup
ne doit pas être averti de la fermeture du terminal auquel il était connecté. Vous devrez ignorer le signal SIGHUP
délivré par le processus à la fin de la session en cours.
Si le fichier de sortie standard était lié à un terminal, il devrait être redirigé vers un fichier défini par la macro NOHUP_OUT_FILE
.
Pour tester, exécutez
./ mynohup sleep 120 &
Après le lancement, fermez la session shell en cours: soit en envoyant un signal SIGHUP, soit en utilisant l’icône «X» située à droite de la fenêtre.
Depuis une autre console, exécutez
ps -ef | grep sleep
Qui est le nouveau parent du processus?
L'utilisation de la commande exit
ou de la combinaison de touches Ctrl-d
n'enverra pas un signal SIGHUP au processus de veille; vous pouvez tester en utilisant sleep 120 &
, fermez le shell actuel en utilisant l'une des deux méthodes, puis vérifiez que le processus est toujours en cours d'exécution.
Allez dans le répertoire 6-zombie
et regardez le contenu de mkzombie.c
et de nozombie.c
. Chaque programme créera un nouveau processus enfant qui appellera uniquement exit
.
Déployez mkzombie
sans attendre la fin de l'enfant. Le processus parent attendra TIMEOUT
secondes et quittera (suivez TODO ).
Depuis une autre console, lancez:
ps -eF | grep zombie
Notez que le processus enfant, bien qu’il ne soit pas en cours d’exécution, apparaît dans la liste des processus sous la forme defunct
et comporte un pid (unique pour le système à ce moment-là). Vous remarquez également qu’après la mort du processus parent, le processus zombie disparaît.
Déployez nozombie
sans utiliser les fonctions 'wait' wait afin que le processus bébé ne passe pas à l'état de zombie. nozombie
attendra TIMEOUT
quelques secondes et sortira. Utilisez le signal SIGCHLD
(des informations sont disponibles dans sigaction(2) et attente (2)). Voir également les sections Traitement du signal et Création d'un processus Linux.