quel sens asynchrone IO faire si le thread est bloqué quand même (voir exemple)

Question

J'ai trouvé un example pour le téléchargement async ftp sur msdn qui fait l'(extrait) suivant:

 // Asynchronously get the stream for the file contents. 
     request.BeginGetRequestStream(
      new AsyncCallback (EndGetStreamCallback), 
      state 
     ); 

     // Block the current thread until all operations are complete. 
     waitObject.WaitOne(); 

La chose ce que je fais pas comprendre ici est, quel sens fait as-asynchrone si le thread est bloqué de toute façon avec un waithandle explicite. J'ai toujours pensé que l'avantage des E/S asynchrones était que l'utilisateur/le programme devait attendre et non.

Answer 1

C'est juste un exemple.

Dans une application Real World (TM), votre code peut exécuter le thread graphique. Et nous savons tous que le blocage du thread de l'interface graphique est tueur quand il s'agit de l'expérience utilisateur. Une fois l'opération asynchrone terminée, elle appelle une sorte de notificateur dans votre interface graphique, ce qui permet à l'utilisateur de faire d'autres choses en attendant que le transfert se termine.

Answer 2

Cela pourrait être fait uniquement pour l'exemple - en utilisant le code minimum nécessaire pour montrer comment cela est fait. Ce que vous obtenez du code ci-dessus est que le thread principal n'utilise pas de CPU en attendant que l'opération se termine - ce qui pourrait être logique si vous utilisez l'interface graphique.

Answer 3

Oui, cela n'a pas beaucoup de sens. Je suppose que le but de l'exemple est de démontrer la syntaxe de l'appeler de façon asynchrone, mais vous avez raison, si vous allez juste bloquer, vous rejetez le point de l'appel asynchrone en premier lieu.