WinAsyncAPPCEx
La fonction WinAsyncAPPCEx fournit un point d’entrée asynchrone pour tous les verbes APPC. Utilisez cette fonction au lieu des versions bloquantes des verbes pour permettre la gestion de plusieurs sessions sur le même thread à l’aide d’événements. Ce verbe est uniquement pris en charge sur Microsoft Windows et utilise des événements Win32®.
Syntaxe
HANDLE WINAPI WinAsyncAPPCEx(
HANDLEevent_handle,
longlpVcb);
Paramètres
event_handle
Handle utilisé pour la notification d’événements à l’aide d’événements Win32.
lpVcb
Pointeur vers le bloc de contrôle de verbe.
Valeur renvoyée
La valeur de retour spécifie si la demande de résolution asynchrone a réussi. Si la fonction a réussi, la valeur de retour est un handle de tâche asynchrone. Si la fonction n’a pas réussi, un zéro est retourné.
Lorsque cette fonction retourne avec une valeur réussie, cela n’indique pas que l’appel APPC sera finalement retourné avec succès. Elle indique uniquement qu’il était possible pour la bibliothèque APPC de tenter l’appel APPC de manière asynchrone à l’aide d’événements pour la notification.
Remarques
Cette fonction est destinée à être utilisée avec WaitForSingleObject ou WaitForMultipleObjects dans l’API Win32. Ces fonctions sont décrites dans la section « Référence » de la documentation du Kit de développement logiciel (SDK) de plateforme Microsoft.
Pour obtenir un exemple d’utilisation de ce verbe dans les TPs multithreads, consultez les exemples d’envoi et de réception multithreads (MRCV). C, MSEND. C et MSENDRCV. C situé dans le dossier MSENDRCV) inclus dans le Kit de développement logiciel (SDK).
Les verbes APPC utilisés dans les conversations de base qui peuvent être bloqués sont les suivants :
-
Les verbes APPC utilisés dans les conversations mappées qui peuvent être bloquées sont les suivants :
-
Lorsque vous utilisez les versions synchrones ou asynchrones d’un verbe, une application ne peut avoir qu’une seule fonction en cours sur une conversation à la fois. Une tentative de lancement d’une deuxième fonction entraîne le code d’erreur AP_CONV_BUSY.
Notes
Les exceptions au paragraphe précédent sont RECEIVE_AND_POST, MC_RECEIVE_AND_POST, RECEIVE_AND_WAIT et MC_RECEIVE_AND_WAIT.
Notes
Pour permettre l’utilisation complète de la prise en charge asynchrone, les verbes RECEIVE_AND_WAIT et MC_RECEIVE_AND_WAIT émis de manière asynchrone ont été modifiés pour agir comme les verbes RECEIVE_AND_POST et MC_RECEIVE_AND_POST . Plus précisément, bien qu’une version asynchrone de l’un de ces verbes soit en suspens, les verbes suivants peuvent être émis sur la même conversation :
LIBÉRER (AP_ABEND_PROG, AP_ABEND_SVC ou AP_ABEND_TIMER)
Notes
Cela permet à une application, en particulier une application serveur, d’utiliser une RECEIVE_AND_WAIT asynchrone ou MC_RECEIVE_AND_WAIT pour recevoir des données. Bien que le RECEIVE_AND_POST, MC_RECEIVE_AND_POST, RECEIVE_AND_WAIT ou MC_RECEIVE_AND_WAIT soit exceptionnel, il peut toujours utiliser SEND_ERROR ou MC_SEND_ERROR et REQUEST_TO_SEND ou MC_REQUEST_TO_SEND. Il est recommandé d’utiliser cette fonctionnalité pour une prise en charge asynchrone complète, et en particulier pour la prise en charge de plusieurs conversations sur le même thread.
Une fois l’opération asynchrone terminée, l’application est avertie par le biais de la signalisation de l’événement. Lors de la signalisation de l’événement, examinez le code de retour principal APPC et le code de retour secondaire dans le bloc de contrôle de verbe pour rechercher les conditions d’erreur éventuelles.