XAsyncBlock
Examinons XAsyncBlock en détail. Il s’agit d’une structure définie comme suit :- queue : un XTaskQueueHandle, c’est-à-dire un handle représentant des informations sur l’endroit où exécuter une unité de travail. Si ce paramètre n’est pas défini, une file d’attente par défaut est utilisée.
- context : vous permet de transmettre des données à la fonction de rappel.
- callback : une fonction de rappel facultative qui est appelée une fois le travail asynchrone terminé. Si vous ne spécifiez pas de rappel, vous pouvez attendre la fin de XAsyncBlock avec XAsyncGetStatus, puis obtenir les résultats.
Important : Un XAsyncBlock doit rester en mémoire jusqu’à la fin de la tâche asynchrone. S’il est alloué dynamiquement, il peut être supprimé dans le rappel d’achèvement de XAsyncBlock.
Attendre une tâche asynchrone
Vous pouvez savoir qu’une tâche asynchrone est terminée de deux manières :- Le rappel d’achèvement de XAsyncBlock est appelé.
- Appelez XAsyncGetStatus avec la valeur true pour attendre sa fin.
Obtenir le résultat de la tâche asynchrone
Pour obtenir le résultat, la plupart des fonctions d’API asynchrones disposent d’une fonction Result correspondante qui reçoit le résultat de l’appel asynchrone. Dans notre exemple de code, PFProfilesGetProfileAsync dispose d’une fonction PFProfilesGetProfileGetResult correspondante. Vous pouvez utiliser cette fonction pour récupérer le résultat de la fonction et agir en conséquence. Pour plus de détails sur la récupération des résultats, consultez la documentation de chaque fonction d’API asynchrone.XTaskQueueHandle
XTaskQueueHandle vous permet de déterminer quel thread exécute la tâche asynchrone et quel thread appelle le rappel d’achèvement de XAsyncBlock. Vous pouvez contrôler le thread qui effectue ces opérations en définissant un mode de distribution. Les modes de distribution suivants sont disponibles :- Manual : la file d’attente manuelle n’est pas distribuée automatiquement. C’est au développeur de distribuer les éléments sur le thread de son choix. Ce mode permet d’affecter le travail ou le rappel d’un appel asynchrone à un thread spécifique.
- Thread Pool : distribue à l’aide d’un pool de threads. Le pool de threads appelle les éléments en parallèle, en prenant à tour de rôle un appel à exécuter dans la file d’attente à mesure que des threads du pool deviennent disponibles. Thread Pool est le plus simple à utiliser, mais c’est celui qui vous donne le moins de contrôle sur le thread utilisé.
- Serialized Thread Pool : distribue à l’aide d’un pool de threads. Le pool de threads appelle les éléments en série, en prenant à tour de rôle un appel à exécuter dans la file d’attente à mesure que l’unique thread du pool devient disponible.
- Immediate : distribue immédiatement le travail mis en file d’attente sur le thread à partir duquel il a été soumis.
Distribution manuelle d’un XTaskQueueHandle
Si vous avez utilisé le mode de distribution manuelle pour la file d’attente de travail ou d’achèvement d’un XTaskQueueHandle, vous devez effectuer la distribution manuellement. Supposons qu’un XTaskQueueHandle ait été créé avec la file d’attente de travail et la file d’attente d’achèvement toutes deux définies sur une distribution manuelle, comme ceci :- queue : la file d’attente sur laquelle distribuer le travail.
- port : une instance de l’énumération XTaskQueuePort.
- timeoutInMs : un uint32_t indiquant le délai d’expiration en millisecondes.
Quand appeler XTaskQueueDispatch
Pour savoir quand la file d’attente a reçu un nouvel élément, vous pouvez appeler XTaskQueueRegisterMonitor afin de définir un gestionnaire d’événements qui indique à votre code que du travail ou des achèvements sont prêts à être distribués.- queue : la file d’attente asynchrone pour laquelle vous soumettez le rappel.
- callbackContext : un pointeur vers les données à transmettre au rappel de soumission.
- callback : la fonction appelée lorsqu’un nouveau rappel est soumis à la file d’attente.
- token : un jeton utilisé ultérieurement lors d’un appel à XTaskQueueUnregisterMonitor pour supprimer le rappel.
