La méthode asynchrone démarre AsyncCallback dans le thread en cours (thread principal)

Question

Il existe un serveur de classe TcpListener. Il accepte les connexions entrantes à l'aide de la méthode BeginAcceptTcpClient (AsyncCallback, Object).

Le code est écrit dans l'exemple MSDN

public static ManualResetEvent tcpClientConnected = 
    new ManualResetEvent(false); 

public static void DoBeginAcceptTcpClient(TcpListener 
    listener) 
{ 
    while(true) 
    { 
     tcpClientConnected.Reset(); 
     Console.WriteLine("Waiting for a connection..."); 
     listener.BeginAcceptTcpClient(
      new AsyncCallback(DoAcceptTcpClientCallback), 
      listener); 
     tcpClientConnected.WaitOne(); 
    } 
} 
public static void DoAcceptTcpClientCallback(IAsyncResult ar) 
{ 
    TcpListener listener = (TcpListener) ar.AsyncState; 
    TcpClient client = listener.EndAcceptTcpClient(ar); 
    Console.WriteLine("Client connected completed"); 
    tcpClientConnected.Set(); 
    while(true) 
    { 
     //Receiving messages from the client 
    } 
} 

Le problème est que le DoAcceptTcpClientCallback (IAsyncResult ar) Méthode parfois commence à exécuter dans le thread courant (principal), et non pas la nouvelle, et des blocs c'est (principal). Pour cette raison, les connexions suivantes ne peuvent pas être reçues. S'il vous plaît aider à comprendre pourquoi ne pas créer un fil pour cette méthode

Answer 1

Oui, comme vous avez découvert, you're not guaranteed that your AsyncCallback is called on a new thread. Fondamentalement, si une opération asynchrone se termine si rapidement que le rappel peut être exécuté de manière synchrone à partir du même thread, il le fera. Cela se produit lorsque, au moment où les appels BeginXXX veulent retourner dans l'ancien modèle asynchrone, la chose que vous attendez est déjà arrivée, par ex. Dans votre cas une connexion, afin d'éviter un changement de contexte inutile, il définit IAsyncResult.CompletedSynchronously à true et exécute votre callback de façon synchrone ce qui dans votre exemple bloque infiniment le thread dans la boucle while (true), ne le laissant jamais revenir de l'appel BeginAcceptTcpClient.

Vous devez tenir compte de ce scénario dans votre méthode de rappel en continuant à rester asynchrone et à revenir rapidement.

De même, regardez dans async/await, ils facilitent la programmation asynchrone.