"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.