WEBVTT 00:04.880 --> 00:11.630 L'API suivante que nous allons aborder est celle qui permet à un processus de prendre un message dans la file 00:11.630 --> 00:12.530 d'attente. 00:12.980 --> 00:16.610 L'API est donc une file d'attente de messages avec un trait de soulignement pour la réception. 00:17.930 --> 00:23.960 Le message que vous recevez concerne donc la récupération d'un message dans la file d'attente des messages référencée par le descripteur file d'attente 00:23.960 --> 00:24.800 des messages. 00:25.340 --> 00:29.570 Il s'agit donc de la file d'attente de messages à partir de laquelle nous essayons de récupérer un message. 00:29.990 --> 00:36.800 Le pointeur de message qui est le deuxième argument de cette API est un pointeur vers le tampon 00:36.800 --> 00:42.770 de message vide car MQ receive va remplir ce tampon avec le message reçu. 00:43.130 --> 00:49.400 Par conséquent, le deuxième pointeur de cette API est un pointeur sur le tampon de message vide et la longueur du message 00:49.400 --> 00:51.740 est la taille du tampon en octets. 00:52.580 --> 00:59.480 Le message le plus ancien et le plus prioritaire est supprimé de la file d'attente des messages et transmis au processus 00:59.480 --> 01:02.630 dans le tampon indiqué par le pointeur de message. 01:03.710 --> 01:10.820 Si le processus de réception a transmis un pointeur sur un entier non signé en tant que quatrième argument de 01:10.820 --> 01:18.270 cet appel de fonction, la valeur de cet entier sera fixée à la priorité du message extrait de la file d'attente des 01:18.270 --> 01:19.200 messages. 01:20.010 --> 01:26.730 En d'autres termes, la priorité du message reçu sera stockée dans l'entier pointé par ce pointeur. 01:26.940 --> 01:32.700 Ainsi, le processus de réception peut connaître la priorité du message qui est extrait de la file d'attente. 01:33.750 --> 01:37.950 Ensuite, le comportement par défaut du message que vous recevez est le blocage. 01:37.950 --> 01:43.410 S'il n'y a pas de messages dans la file d'attente, c'est-à-dire si le processus de réception invoque 01:43.410 --> 01:49.590 la fonction de réception de la file d'attente des messages et s'il n'y a pas de messages dans la file d'attente des 01:49.590 --> 01:52.050 messages, cette fonction sera bloquée. 01:53.540 --> 01:55.690 Il s'agit donc du comportement par défaut. 01:55.700 --> 02:02.150 Toutefois, si le processus de réception ne souhaite pas ce comportement, c'est-à-dire lorsque la file d'attente des messages est vide et que le processus 02:02.180 --> 02:09.170 de réception invoque la réception de la file d'attente des messages sur la file d'attente des messages, et si le processus de réception ne souhaite pas que cette fonction 02:09.170 --> 02:15.800 soit bloquée, alors pendant l'ouverture de la file d'attente des messages, c'est-à-dire lorsque le processus de réception a invoqué l'ouverture de la file 02:15.830 --> 02:20.210 d'attente des messages, le processus de réception ne peut pas bloquer cette fonction. 02:20.930 --> 02:26.250 Sur la file d'attente des messages, il aurait dû spécifier cet indicateur dans l'API d'ouverture de la file d'attente des messages. 02:26.870 --> 02:31.820 Cette option modifie donc le comportement par défaut de l'API de réception de la file d'attente de messages. 02:32.780 --> 02:39.890 Ainsi, si la file d'attente des messages est vide, la réception de la file d'attente 02:39.890 --> 02:47.540 des messages est immédiatement renvoyée avec le numéro d'erreur E dès le succès. 02:47.540 --> 02:53.030 L'API de réception de la file d'attente de messages renvoie le nombre d'octets reçus dans le tampon désigné par 02:53.030 --> 02:54.240 le pointeur de message. 02:54.240 --> 02:59.550 Vous pouvez donc constater que la valeur de retour de cette API est le nombre d'octets du message 02:59.550 --> 03:00.120 reçu. 03:00.120 --> 03:05.520 Et pour une raison quelconque, si elle échoue, la valeur de retour de cette API est moins un.