Question

I’m about 15 minutes into my first play with the async CTP… (nice).

Here’s a really simple server I’ve knocked together:

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");
        }
    }
}

As can be seen, the async method Go calls itself. In classic non-async world, this would cause a stack overflow. I assume that this isn’t the case with an async method, but I’d like to be sure, one way or the other. Anyone?

Answer 1

Let’s break it down into something simpler:

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

How does the compiler deal with this?

Basically this becomes something like this sketch:

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();
    }

Now all you have to remember is that when each asynchronous operation completes, “DoIt” is scheduled to be called again by the message loop (on the appropriate instance of the helper of course).

So what happens? Work it out. You call Go for the first time. That makes helper number one and calls DoIt. That calls Something(), gets a task back, makes an awaiter for that task, tells the awaiter “when you’re done, call helper1.DoIt” and returns.

A tenth of a second later the task completes and the message loop calls helper1’s DoIt. helper1’s state is AFTERSOMETHINGSTATE, so we take the goto and call Go. That makes helper2 and calls DoIt on that. That calls Something(), gets a task back, makes an awaiter for that task, tells the awaiter “when you’re done, call DoIt on helper2” and returns control back to helper1’s DoIt. That calls SomethingElse, makes an awaiter for that task, and tells it “when you’re done doing something else, call helper1’s DoIt”. It then returns.

Now we have two tasks outstanding and no code on the stack. One of the tasks will complete first. Suppose the SomethingElse task completes first. The message loop calls helper1.DoIt(), which immediately returns. Helper1 is now garbage.

Later the message loop calls helper2.DoIt(), and branches to AFTERSOMETHING. Now Go() is called, which creates helper3…

So no, there’s no unbounded recursion here. Every time Go executes it runs as far as asynchronously starting Something() and then it returns to its caller. The call to the stuff after “something” happens later. “Go” is only ever on the stack once at a time.