async ctp recursion

Question

Estoy a unos 15 minutos de mi primera jugada con el async CTP ... (agradable).

Aquí es un servidor muy simple que he entrechocaban:

internal class Server 
{ 
    private HttpListener listener; 
    public Server() 
    { 
     listener = new HttpListener(); 
     listener.Prefixes.Add("http://*:80/asynctest/"); 
     listener.Start(); 
     Go(); 
    } 

    async void Go() 
    { 
     HttpListenerContext context = await listener.GetContextAsync(); 
     Go(); 
     using (var httpListenerResponse = context.Response) 
     using (var outputStream = httpListenerResponse.OutputStream) 
     using (var sw = new StreamWriter(outputStream)) 
     { 
      await sw.WriteAsync("hello world"); 
     } 
    } 
} 

Como se puede observar, el método asíncrono Go llama a sí misma. En el mundo clásico no asincrónico, esto causaría un desbordamiento de la pila. Supongo que este no es el caso con un método asíncrono, pero me gustaría estar seguro, de una forma u otra. ¿Nadie?

Answer 1

Vamos a romper hacia abajo en algo más simple:

async static void Go() 
{ 
    await Something(); 
    Go(); 
    await SomethingElse(); 
} 

¿Cómo trata el compilador con esto?

Básicamente esto se convierte en algo parecido a este bosquejo:

class HelperClass 
{ 
    private State state = STARTSTATE; 
    public void DoIt() 
    { 

     if (state == STARTSTATE) goto START; 
     if (state == AFTERSOMETHINGSTATE) goto AFTERSOMETHING; 
     if (state == AFTERSOMETHINGELSESTATE) goto AFTERSOMETHINGELSE; 

     START: 
     { 
      state = AFTERSOMETHINGSTATE; 
      var awaiter = Something().MakeAnAwaiter(); 
      awaiter.WhenDoneDo(DoIt); 
      return; 
     } 

     AFTERSOMETHING: 
     { 
      Go(); 
      state = AFTERSOMETHINGELSESTATE; 
      var awaiter = SomethingElse().MakeAnAwaiter(); 
      awaiter.WhenDoneDo(DoIt); 
      return; 
     } 

     AFTERSOMETHINGELSE: 

     return; 
    } 

    static void Go() 
    { 
     var helper = new HelperClass(); 
     helper.DoIt(); 
    } 

Ahora todo lo que tiene que recordar es que cuando cada operación asincrónica, "DoIt" está programado para ser llamado de nuevo por el bucle de mensajes (en la apropiada instancia del ayudante, por supuesto).

¿Qué sucede? Resolverlo. Llamas a Go por primera vez. Eso hace que el asistente sea el número uno y llame a DoIt. Eso llama a Something(), recupera una tarea, hace una espera para esa tarea, le dice al que espera "cuando hayas terminado, llama a helper1.DoIt" y regresa.

Una décima de segundo más tarde la tarea se completa y el bucle de mensaje llama al DoIt de helper1. El estado de helper1 es AFTERSOMETHINGSTATE, así que tomamos el goto y llamamos a Go. Eso hace que helper2 y llame a DoIt sobre eso. Eso llama a Something(), recupera una tarea, hace una espera para esa tarea, le dice al que espera "cuando hayas terminado, llama a DoIt en helper2" y devuelve el control a DoIt de helper1. Eso llama a SomethingElse, hace que alguien lo aguarde y le dice "cuando termines de hacer otra cosa, llama a doit de helper1". Luego regresa.

Ahora tenemos dos tareas pendientes y ningún código en la pila. Una de las tareas se completará primero. Supongamos que la tarea SomethingElse se completa primero. El bucle de mensaje llama a helper1.DoIt(), que devuelve inmediatamente. Helper1 ahora es basura.

Más tarde, el bucle de mensaje llama a helper2.DoIt() y se ramifica a AFTERSOMETHING. Ahora se llama a Go(), que crea helper3 ...

Así que no, no hay recursividad ilimitada aquí. Cada vez que Go se ejecuta, se ejecuta hasta que se inicie asincrónicamente Something() y luego vuelve a su llamador. La llamada a las cosas después de "algo" sucede más tarde. "Ir" solo está en la pila una vez a la vez.