WEBVTT 00:05.180 --> 00:11.930 La dernière API dont nous allons parler est celle qui permet à un processus de détruire une file d'attente 00:11.930 --> 00:12.950 de messages. 00:12.980 --> 00:19.700 En d'autres termes, un processus peut demander au système d'exploitation de libérer la file d'attente des messages en tant que ressource du noyau. 00:19.880 --> 00:27.110 L'API s'appelle maintenant message queue unlink et l'argument de cette API est en fait l'identifiant de la file d'attente de messages. 00:27.530 --> 00:30.770 Ainsi, le message queue unlink détruit la file d'attente des messages. 00:31.760 --> 00:35.450 Détruire la file d'attente des messages signifie libérer la ressource du noyau. 00:36.550 --> 00:43.390 Lorsque le processus invoque cette API, il indique en fait au système d'exploitation que lorsque cette 00:43.390 --> 00:50.470 file de messages n'est plus utilisée par aucun autre processus, il suffit de la détruire complètement. 00:50.980 --> 00:54.070 Il doit donc être appelé lorsque le processus a été invoqué. 00:54.070 --> 00:57.160 Fermeture de la file d'attente de messages sur la file d'attente de messages. 00:57.920 --> 00:58.400 C'est vrai. 00:58.400 --> 01:03.590 Ainsi, lorsque le processus a invoqué la fermeture de la file d'attente des messages, la file d'attente des messages est fermée. 01:03.800 --> 01:09.800 La prochaine chose que le processus doit faire est d'invoquer l'API de déliaison de la file d'attente de messages. 01:10.160 --> 01:15.710 En général, le créateur du processus doit détruire la file d'attente des messages. 01:16.100 --> 01:22.550 En général, le processus qui crée la file d'attente des messages devrait également être celui 01:22.550 --> 01:24.680 qui détruit la file d'attente. 01:24.950 --> 01:30.620 Ainsi, le processus qui a créé la file d'attente de messages pour la première fois doit invoquer 01:30.620 --> 01:35.540 l'API de déliaison de la file d'attente de messages pour la détruire. 01:35.900 --> 01:41.850 Cette API renvoie moins un si elle échoue pour une raison quelconque et renvoie zéro en cas de succès. 01:41.870 --> 01:49.210 Et bien sûr, l'effet de l'invocation de cette API sur une file d'attente de messages est reporté. 01:49.220 --> 01:53.480 Si d'autres processus utilisent actuellement la file d'attente des messages. 01:53.510 --> 01:59.670 Pour comprendre ce point, supposons qu'il existe un processus P 1 et que ce processus P 1 a créé une file 01:59.670 --> 02:03.420 d'attente de messages pour la première fois, n'est-ce pas ? 02:03.420 --> 02:04.230 C'est donc ce processus qui est à l'œuvre. 02:04.260 --> 02:06.390 P one est en fait le propriétaire de la file d'attente des messages. 02:06.600 --> 02:12.600 Et à un moment donné, supposons qu'il y ait un processus P 2 qui utilise également la file d'attente des messages et qu'il y ait un 02:12.600 --> 02:15.870 processus P 3 qui utilise également la file d'attente des messages. 02:16.110 --> 02:24.630 Supposons maintenant qu'à ce stade, le processus p one ait invoqué l'API "message queue unlinked" sur cette file de 02:24.630 --> 02:25.530 messages. 02:25.560 --> 02:26.730 C'est le processus. 02:26.760 --> 02:31.020 P one demande en fait au système d'exploitation de détruire cette file d'attente de messages. 02:31.320 --> 02:38.730 Mais le système d'exploitation ne détruira pas cette file de messages et reportera sa destruction jusqu'au moment où 02:38.730 --> 02:44.640 tous les processus qui utilisent cette file de messages, c'est-à-dire le processus P-2 et le 02:44.640 --> 02:50.970 processus P-3, invoqueront l'API de fermeture de la file de messages sur cette file de messages. 02:52.900 --> 02:59.200 Dès que le système d'exploitation détecte que le nombre de références de ce message 02:59.770 --> 03:06.520 est tombé à zéro, il est le seul à effectuer l'invocation d'annulation de lien sur cette file 03:06.550 --> 03:12.280 d'attente de messages et à détruire complètement cette file d'attente.