WEBVTT 00:05.340 --> 00:11.240 Donc, les gars, en allant de l'avant, nous allons discuter des façons de générer des signaux dans Linux. 00:11.250 --> 00:15.630 Il y a donc exactement trois façons de générer un signal sous Linux. 00:15.930 --> 00:20.580 La première méthode consiste à émettre un signal à partir du système d'exploitation OS deux. 00:21.000 --> 00:26.970 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é 00:26.970 --> 00:30.210 à un processus s'exécutant dans l'espace utilisateur. 00:30.420 --> 00:37.620 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 00:37.620 --> 00:40.440 l'on appuie sur une touche de contrôle. 00:41.140 --> 00:45.910 Il s'agit donc d'une façon de générer un signal et de le transmettre à un processus. 00:46.000 --> 00:53.350 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 00:53.350 --> 00:56.550 être délivré par le processus A à lui-même. 00:57.410 --> 01:04.550 Nous verrons qu'un processus peut utiliser l'appel de système de rayons afin 01:04.550 --> 01:09.590 de générer un signal et de traiter le signal lui-même. 01:11.460 --> 01:17.730 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 01:17.730 --> 01:22.020 transmis à un autre processus B, qui s'exécute dans l'espace utilisateur. 01:22.050 --> 01:22.650 C'est vrai. 01:22.650 --> 01:28.710 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". 01:28.980 --> 01:34.530 Nous allons donc passer en revue les exemples de chacune de ces façons de générer un signal sous Linux. 01:35.460 --> 01:40.200 Voyons comment les trois façons de générer un signal peuvent être mises en œuvre. 01:40.230 --> 01:44.040 La première façon de générer un signal s'appelle le piégeage du signal. 01:44.430 --> 01:50.430 Un processus peut piéger un signal reçu du système d'exploitation et le processus peut exécuter une fonction 01:50.430 --> 01:53.430 définie par l'utilisateur lorsque ce signal est reçu. 01:53.580 --> 01:54.210 C'est vrai. 01:54.210 --> 02:00.360 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. 02:00.390 --> 02:03.540 Par exemple, le signal Sigkill ne peut pas être piégé. 02:04.350 --> 02:11.560 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 02:11.560 --> 02:13.330 traitement personnalisé. 02:13.480 --> 02:18.250 Il suffit donc d'inclure le fichier hash, include signal dot h, n'est-ce pas ? 02:18.430 --> 02:24.310 Le système d'exploitation Linux fournit une API de signal en utilisant cette API de signal. 02:24.340 --> 02:31.210 Vous pouvez enregistrer la routine de gestion du signal par rapport au signal. 02:31.330 --> 02:40.480 Cela signifie que si cette application reçoit le signal sig int, le gestionnaire correspondant qui doit être invoqué 02:40.480 --> 02:47.290 est cette fonction qui est le gestionnaire du signal control C underscore. 02:47.290 --> 02:51.910 Cette routine est donc la routine de gestion du signal sig. 02:51.910 --> 02:53.590 INT Droit. 02:53.590 --> 02:57.250 Cette étape est donc appelée enregistrement d'un signal. 02:57.340 --> 03:03.580 En d'autres termes, nous lions la routine de traitement du signal au numéro du signal. 03:04.520 --> 03:05.150 C'est vrai. 03:06.200 --> 03:10.460 Ici, vous pouvez fournir l'implémentation de la routine de gestion des signaux. 03:10.760 --> 03:15.650 Je n'ai fourni ici qu'une implémentation très triviale de la routine de gestion des signaux. 03:16.100 --> 03:20.240 Le code source complet est donc listé sur la droite ici. 03:21.400 --> 03:23.980 Vous pouvez donc voir cela dans la fonction principale. 03:23.980 --> 03:29.770 Mon application enregistre en fait deux routines de gestion des signaux pour les deux types de signaux 03:29.770 --> 03:30.530 différents. 03:30.550 --> 03:36.520 Le premier type de signal est le Sigint, et le second type de signal est le signal d'abandon. 03:36.790 --> 03:37.420 C'est vrai. 03:37.420 --> 03:42.850 Ici, l'application vous demande si vous souhaitez interrompre le processus ou non. 03:44.130 --> 03:49.380 Si l'utilisateur entre, pourquoi alors l'abandon est un appel système fourni par l'API Linux. 03:49.410 --> 03:58.050 Lorsque cet appel système est invoqué, le système d'exploitation génère le signal Sig abort et le transmet 03:58.080 --> 03:59.250 au processus. 04:00.170 --> 04:05.600 Pour l'instant, car disons qu'un utilisateur a saisi Y. 04:05.630 --> 04:11.350 Le système d'exploitation a donc envoyé ce signal d'abandon à ce processus. 04:11.360 --> 04:17.510 Mais maintenant, nous avons une routine de gestion des signaux qui va être invoquée. 04:18.590 --> 04:22.190 En réponse à la réception du signal à bord. 04:22.550 --> 04:30.440 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. 04:31.770 --> 04:36.390 C'est ainsi que le signal d'abandon de sig est piégé par le processus. 04:36.390 --> 04:43.480 Et le processus a exécuté sa routine de gestion des signaux en réponse à la réception du signal d'abandon. 04:43.500 --> 04:46.980 Mais qu'en est-il du signal sig ? 04:47.010 --> 04:52.890 Nous savons maintenant que le signal Sigint est généré par le système d'exploitation et transmis au processus 04:52.890 --> 04:56.430 lorsque l'utilisateur appuie sur Ctrl C, Droite. 04:56.430 --> 05:03.840 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 05:03.840 --> 05:09.120 que le système d'exploitation générera un signal Sigint et que ce signal sera transmis à ce 05:09.120 --> 05:09.870 processus. 05:09.870 --> 05:17.640 Et comme ce processus a enregistré son gestionnaire de signal avec ce signal, la routine "Control see signal 05:17.640 --> 05:19.650 handler" sera invoquée. 05:20.810 --> 05:25.190 Essayons donc d'exécuter ce programme dans la pratique. 05:26.020 --> 05:28.240 Il s'agit donc d'un programme assez simple. 05:28.450 --> 05:33.940 Je vous conseille de taper ce petit programme sur votre machine et de l'essayer. 05:34.620 --> 05:41.130 La deuxième technique de génération d'un signal est qu'un processus peut générer et s'envoyer un signal 05:41.130 --> 05:44.430 à lui-même en utilisant l'appel système raise. 05:44.610 --> 05:47.630 Le synopsis de l'appel système raise est donc assez simple. 05:47.640 --> 05:50.780 Il accepte simplement un argument, qui est le numéro du signal. 05:50.790 --> 05:57.840 Ainsi, au moment où cet appel système raise est invoqué, un numéro de signal spécifié en tant qu'argument 05:57.840 --> 06:00.960 sera délivré à ce processus. 06:00.960 --> 06:07.890 Et si le processus dispose d'un gestionnaire de signal enregistré pour ce numéro de signal, ce gestionnaire 06:07.890 --> 06:09.120 sera invoqué. 06:09.750 --> 06:15.990 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 06:15.990 --> 06:16.840 lui-même. 06:16.860 --> 06:20.400 Essayons donc de comprendre cela à l'aide d'un exemple. 06:22.020 --> 06:28.650 Dans cet exemple, vous pouvez voir qu'à l'intérieur de la fonction principale, nous enregistrons immédiatement le gestionnaire 06:28.650 --> 06:30.440 de signal avec le type de signal. 06:30.450 --> 06:35.220 On voit donc ici que le type du signal est sig int, ce qui correspond au contrôle C. 06:36.380 --> 06:39.170 Le gestionnaire de signal correspondant est cette fonction. 06:39.200 --> 06:42.590 La mise en œuvre de cette fonction est décrite ci-dessous. 06:43.340 --> 06:44.060 C'est vrai. 06:44.060 --> 06:50.870 Cela signifie qu'à chaque fois que ce processus recevra le signal sig int, ce gestionnaire de signal sera 06:50.870 --> 06:51.740 invoqué. 06:51.920 --> 06:57.740 Vous pouvez voir qu'en dessous, cette application invoque simplement l'appel système raise. 06:59.010 --> 06:59.550 C'est vrai. 06:59.550 --> 07:06.450 Ainsi, dès que l'appel système res est invoqué et que nous transmettons le numéro de signal comme argument à 07:06.450 --> 07:07.920 cet appel système res. 07:08.460 --> 07:13.680 Ainsi, dès que l'appel système res est invoqué, ce processus est livré. 07:13.680 --> 07:15.390 Signal sig int. 07:16.630 --> 07:17.050 C'est vrai. 07:17.050 --> 07:22.990 Et chaque fois que le processus reçoit un signal, puisque nous avons enregistré le gestionnaire de signal pour 07:22.990 --> 07:24.100 ce numéro de signal. 07:24.130 --> 07:28.360 Par conséquent, cette routine de gestion des signaux sera éventuellement invoquée. 07:28.870 --> 07:29.470 C'est vrai. 07:29.470 --> 07:36.580 Dans cet exemple, il n'est pas nécessaire d'appuyer sur Ctrl C car nous utilisons l'appel 07:36.610 --> 07:40.330 système qui délivre le signal à ce processus. 07:41.520 --> 07:42.030 C'est vrai. 07:42.030 --> 07:43.830 Il n'y a donc pas besoin de contrôle. 07:43.890 --> 07:44.360 Vous voyez ? 07:45.200 --> 07:52.040 Je vous conseille donc de compiler et d'exécuter ce programme et de voir ce que vous observez en sortie. 07:54.000 --> 07:59.040 Ces exemples sont donc relativement simples et faciles à comprendre.