Donc, les gars, en allant de l'avant, nous allons discuter des façons de générer des signaux dans Linux.
Il y a donc exactement trois façons de générer un signal sous Linux.
La première méthode consiste à émettre un signal à partir du système d'exploitation OS deux.
La première façon de générer un signal est donc le signal généré par le système d'exploitation et le signal est délivré
à un processus s'exécutant dans l'espace utilisateur.
L'exemple de ce signal est le signal Sigint, qui est généré par le système d'exploitation et transmis au processus lorsque
l'on appuie sur une touche de contrôle.
Il s'agit donc d'une façon de générer un signal et de le transmettre à un processus.
La deuxième façon de générer un signal est qu'un signal peut être généré par le processus lui-même et qu'il peut
être délivré par le processus A à lui-même.
Nous verrons qu'un processus peut utiliser l'appel de système de rayons afin
de générer un signal et de traiter le signal lui-même.
Enfin, un signal peut être généré par le processus A qui s'exécute dans l'espace utilisateur et le signal peut être
transmis à un autre processus B, qui s'exécute dans l'espace utilisateur.
C'est vrai.
Il s'agit donc d'envoyer un signal du processus A au processus B, ce qui peut être fait à l'aide de l'appel système "kill".
Nous allons donc passer en revue les exemples de chacune de ces façons de générer un signal sous Linux.
Voyons comment les trois façons de générer un signal peuvent être mises en œuvre.
La première façon de générer un signal s'appelle le piégeage du signal.
Un processus peut piéger un signal reçu du système d'exploitation et le processus peut exécuter une fonction
définie par l'utilisateur lorsque ce signal est reçu.
C'est vrai.
C'est ce qu'on appelle le piégeage des signaux, et nous avons déjà discuté du fait que tous les signaux ne peuvent pas être piégés.
Par exemple, le signal Sigkill ne peut pas être piégé.
Discutons donc de la mise en œuvre qui concerne la façon dont les signaux peuvent être piégés et la façon dont le processus peut effectuer son propre
traitement personnalisé.
Il suffit donc d'inclure le fichier hash, include signal dot h, n'est-ce pas ?
Le système d'exploitation Linux fournit une API de signal en utilisant cette API de signal.
Vous pouvez enregistrer la routine de gestion du signal par rapport au signal.
Cela signifie que si cette application reçoit le signal sig int, le gestionnaire correspondant qui doit être invoqué
est cette fonction qui est le gestionnaire du signal control C underscore.
Cette routine est donc la routine de gestion du signal sig.
INT Droit.
Cette étape est donc appelée enregistrement d'un signal.
En d'autres termes, nous lions la routine de traitement du signal au numéro du signal.
C'est vrai.
Ici, vous pouvez fournir l'implémentation de la routine de gestion des signaux.
Je n'ai fourni ici qu'une implémentation très triviale de la routine de gestion des signaux.
Le code source complet est donc listé sur la droite ici.
Vous pouvez donc voir cela dans la fonction principale.
Mon application enregistre en fait deux routines de gestion des signaux pour les deux types de signaux
différents.
Le premier type de signal est le Sigint, et le second type de signal est le signal d'abandon.
C'est vrai.
Ici, l'application vous demande si vous souhaitez interrompre le processus ou non.
Si l'utilisateur entre, pourquoi alors l'abandon est un appel système fourni par l'API Linux.
Lorsque cet appel système est invoqué, le système d'exploitation génère le signal Sig abort et le transmet
au processus.
Pour l'instant, car disons qu'un utilisateur a saisi Y.
Le système d'exploitation a donc envoyé ce signal d'abandon à ce processus.
Mais maintenant, nous avons une routine de gestion des signaux qui va être invoquée.
En réponse à la réception du signal à bord.
Ainsi, dès que cet appel système d'abandon est invoqué, il entraîne l'invocation de la routine de gestion du signal d'abandon.
C'est ainsi que le signal d'abandon de sig est piégé par le processus.
Et le processus a exécuté sa routine de gestion des signaux en réponse à la réception du signal d'abandon.
Mais qu'en est-il du signal sig ?
Nous savons maintenant que le signal Sigint est généré par le système d'exploitation et transmis au processus
lorsque l'utilisateur appuie sur Ctrl C, Droite.
Vous exécutez donc à nouveau cette application et, au lieu d'entrer le mot "oui" ou "non", vous appuyez sur Ctrl C et vous verrez
que le système d'exploitation générera un signal Sigint et que ce signal sera transmis à ce
processus.
Et comme ce processus a enregistré son gestionnaire de signal avec ce signal, la routine "Control see signal
handler" sera invoquée.
Essayons donc d'exécuter ce programme dans la pratique.
Il s'agit donc d'un programme assez simple.
Je vous conseille de taper ce petit programme sur votre machine et de l'essayer.
La deuxième technique de génération d'un signal est qu'un processus peut générer et s'envoyer un signal
à lui-même en utilisant l'appel système raise.
Le synopsis de l'appel système raise est donc assez simple.
Il accepte simplement un argument, qui est le numéro du signal.
Ainsi, au moment où cet appel système raise est invoqué, un numéro de signal spécifié en tant qu'argument
sera délivré à ce processus.
Et si le processus dispose d'un gestionnaire de signal enregistré pour ce numéro de signal, ce gestionnaire
sera invoqué.
Le signal désigné par un numéro de signal lorsqu'il est émis à l'aide de l'appel système raise est transmis au processus
lui-même.
Essayons donc de comprendre cela à l'aide d'un exemple.
Dans cet exemple, vous pouvez voir qu'à l'intérieur de la fonction principale, nous enregistrons immédiatement le gestionnaire
de signal avec le type de signal.
On voit donc ici que le type du signal est sig int, ce qui correspond au contrôle C.
Le gestionnaire de signal correspondant est cette fonction.
La mise en œuvre de cette fonction est décrite ci-dessous.
C'est vrai.
Cela signifie qu'à chaque fois que ce processus recevra le signal sig int, ce gestionnaire de signal sera
invoqué.
Vous pouvez voir qu'en dessous, cette application invoque simplement l'appel système raise.
C'est vrai.
Ainsi, dès que l'appel système res est invoqué et que nous transmettons le numéro de signal comme argument à
cet appel système res.
Ainsi, dès que l'appel système res est invoqué, ce processus est livré.
Signal sig int.
C'est vrai.
Et chaque fois que le processus reçoit un signal, puisque nous avons enregistré le gestionnaire de signal pour
ce numéro de signal.
Par conséquent, cette routine de gestion des signaux sera éventuellement invoquée.
C'est vrai.
Dans cet exemple, il n'est pas nécessaire d'appuyer sur Ctrl C car nous utilisons l'appel
système qui délivre le signal à ce processus.
C'est vrai.
Il n'y a donc pas besoin de contrôle.
Vous voyez ?
Je vous conseille donc de compiler et d'exécuter ce programme et de voir ce que vous observez en sortie.
Ces exemples sont donc relativement simples et faciles à comprendre.