Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les E/S asynchrones constituent un moyen efficace pour un thread unique de gérer simultanément plusieurs requêtes d’E/S. Le RPC asynchrone sur le serveur effectue un objectif similaire pour les requêtes RPC. Dans les versions de Windows antérieures à Windows Vista, la publication de requêtes d’E/S asynchrones à partir de procédures serveur à l’aide du RPC asynchrone est déconseillée. Toutefois, dans Windows Vista et les versions ultérieures de Windows, les requêtes d’E/S asynchrones associées à un port d’achèvement d’E/S sont prises en charge par RPC asynchrone.
Avant Windows Vista, un appel de procédure distante asynchrone peut se terminer avant la fin de la demande d’E/S asynchrone. Une fois l’appel asynchrone terminé, son thread peut s’arrêter si le runtime RPC décide qu’il dispose de suffisamment de threads disponibles pour traiter la charge de travail attendue. Le système lie toutes les demandes d’E/S au thread qui les initie. Si le thread se termine, toutes les demandes d’E/S en attente sur ce thread sont abandonnées. Les requêtes d’E/S en attente ne peuvent pas être déplacées vers un autre thread.
Par conséquent, les concepteurs d’applications ciblant des versions de Windows antérieures à Windows Vista peuvent utiliser des E/S synchrones dans les procédures serveur, ou ils peuvent transférer toutes les requêtes impliquant des E/S asynchrones vers des procédures s’exécutant sur un pool de threads que l’application gère. L’API Windows fournit des fonctions pour la gestion des pools de threads. Consultez processus et fonctions de thread.