“Iterating” over an async method

Question

A few related questions about the async CTP:

• I can iterate over an Iterator Block (an IEnumerable<T> yield-returning T) using GetEnumerator() and then enumerator methods MoveNext(), and Current(). What is the analog for async methods? How can a non-async calling method to receive and process any awaited items and then ContinueWith()? Can you provide a short example? I'm just not seeing it.

• Also, in this following example async method, MyAwaitable has a GetAwaiter() method. If GetAwaiter() returns a string but THuh is not string, the compiler doesn't complain. What type constraints/expectations exist between THuh and GetAwaiter()?

  async Task<THuh> DoSomething()
  {
       var x = await new MyAwaitable("Foo");
  
       var y = await new MyAwaitable("Bar");
  
       return null;
  } 
  

• Please explain the following line of the C# spec draft. Are async Task<T> methods supposed to return a default(T) which will never be used? I see some samples that do not seem to follow this rule - the return value seems reachable and the value is non-default. Is this value inaccessible? If so, why the awkward inaccessible return statement?

In an asynchronous function with the return type Task<T> for some T, return statements must have an expression that is implicitly convertible to T, and the endpoint of the body must be unreachable.

• The spec says "All of GetAwaiter, IsCompleted, OnCompleted and GetResult are intended to be “non-blocking”" - so then in what method should the (potentially) long-running operation be defined?

Thanks!

Answer 1

I'm trying to convert continuation-passing I did (awkardly but successfully) with Iterator Blocks and converting it to use async instead. I think I'm fighting the new way. Understanding the change feels like tearing apart 3-inch wide strips of Velcro.

I can understand how you might feel that way. I discourage people from trying to build CPS out of iterator blocks because really it is not a good fit, no matter what underlying mechanisms iterators and CPS have in common. Iterator blocks are designed to feel good for quickly making methods that turn data structures into sequences or turn sequences into different sequences; they're not designed to solve the general problem of call-with-current-continuation.

For that matter, async/await isn't precisely call-with-current-continuation either, though it comes an order of magnitude closer, obviously. Async/await is designed to make task-based asynchrony easier; that it does so by rewriting code into a form of continuation passing style is an implementation detail.

This answer I wrote on a related topic might help:

How could the new async feature in c# 5.0 be implemented with call/cc?

I suspect that the conceptual problem that you're having is that in iterator-style asynchrony, the "orchestrator" -- the thing figuring out when the iterator block gets to resume where it left off -- is your code. You write some code and you decide when to call MoveNext to pump the iterator. With task-based asynchrony, some other hunk of code does that for you. When a task completes, odds are good that it posts that fact to a message queue somewhere, and then when the message queue is pumped, the continuation gets activated with the result. There's no explicit "MoveNext" in your code that you can point at; rather, the fact that a task has completed and knows its own continuation is sufficient to ensure that the continuation is put onto a work queue for eventual execution.

If you've got more questions, I encourage you to post them on SO and/or the async forum.

Answer 2

In your DoSomething example, the compiler is not complaining because the type of your MyAwaitable's GetResult method has nothing to do with THuh. The statement that relates to THuh is return null;. The null literal is implicitly convertible to THuh, so all is well.

The IEnumerable keyword that is analogous to await is foreach. await requires a type that fits a certain pattern, and so does foreach. One is a mechanism for consuming awaitable types, the other for consuming enumerable types.

On the other hand, iterator blocks (yield return and yield break) are mechanisms for defining enumerable types (by writing a method rather than explicitly declaring the type). The analogy here is the async keyword.

To elaborate on the analogy between async and yield return, note that an iterator block that returns IEnumerable<int> can contain the statement yield return 42; similarly, an async method that returns Task<int> can contain the statement yield return 42;. Note how in both cases, the type of the return expression is not the return type of the method, but rather the type argument of the method's return type.

---

If you haven't done so yet, you really ought to read Eric Lippert's blog on these topics:

http://blogs.msdn.com/b/ericlippert/archive/tags/Async/

http://blogs.msdn.com/b/ericlippert/archive/tags/Iterators/

Also, posts on on continuation-passing style other than the ones in the Async series can be useful if the concept is new to you (as it was to me):

http://blogs.msdn.com/b/ericlippert/archive/tags/continuation+passing+style/

---

Finally, for examples, see Eric's blog post linking to his MSDN article and related articles in the same issue and the follow-up article by Bill Wagner at http://msdn.microsoft.com/en-us/vstudio/hh533273

EDIT

I see some samples that do not seem to follow this rule - the return value seems reachable and the value is non-default. Is this value inaccessible? If so, why the awkward inaccessible return statement?

The phrase "the endpoint of the body must be unreachable" means that you must have a return statement. The endpoint of the body comes after the return statement, and is made unreachable by the return statement. Example using a normal int-returning method:

public int Main()
{
    Console.WriteLine("X");
    //after this comment is the reachable end point of the body; this method therefore won't compile.
}

public int Main()
{
    Console.WriteLine("X");
    return 0;
    //anything after the return statement is unreachable, including the end point of the body; this method therefore will compile.
}

EDIT 2

Here is a short, trivial example of an awaiter that calculates the last half of a string. The example passes a continuation that prints the result to the console. It's not thread safe!

public static class StringExtensions
{
    public static SubstringAwaiter GetAwaiter(this string s)
    {
        return new SubstringAwaiter(s, s.Length / 2, s.Length - s.Length / 2);
    }
}

public class SubstringAwaiter
{
    private readonly string _value;
    private readonly int _start;
    private readonly int _length;
    private string _result;
    private Action _continuation;

    public SubstringAwaiter(string value, int start, int length)
    {
        _value = value;
        _start = start;
        _length = length;
    }

    public bool IsCompleted { get; private set; }
    public void OnCompleted(Action callback)
    {
        if (callback == null)
            return;

        _continuation += callback;
    }
    public string GetResult()
    {
        if (!IsCompleted)
            throw new InvalidOperationException();
        return _result;
    }
    public void Execute()
    {
        _result = _value.Substring(_start, _length);
        IsCompleted = true;
        if (_continuation != null)
            _continuation();
    }
}

public class Program
{
    public static void Main()
    {
        var awaiter = "HelloWorld".GetAwaiter();
        awaiter.OnCompleted(() => Console.WriteLine(awaiter.GetResult()));
        awaiter.Execute();
    }
}