"Iterating" over an async method
Asked Answered
B

2

2

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!

Berglund answered 8/12, 2011 at 14:56 Comment(0)
A
7

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.

Anemic answered 9/12, 2011 at 1:0 Comment(2)
This is an awesome answer and you nailed it - that was my conceptual disconnect. 1 Is this right?: If I write my own (awaitables and) awaiters, I get to control when IsComplete and I call any continuations registered by the Framework with OnComplete(Action) in MyAwaiter.SetOutcome(). I can use a custom TaskScheduler to write a deterministic, single-file (single-threaded?) scheduling policy. 2 (Where) How easy is it to abandon a tree of continuations (when idle)? I guess the custom TaskScheduler can just choose NOT to schedule any more. Any consequences?Berglund
Hi Eric, Any thoughts on 1 and 2 above?Berglund
E
1

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();
    }
}
Emmeram answered 8/12, 2011 at 18:20 Comment(5)
Thanks for responding. What is the analog of GetEnumerator(), MoveNext(), and Current()? I don't think you can await within a method that is not itself async. How can I call an async method from a non-async method in a very controlled way such that I get access to all of the awaited items for processing? Something to do with DoSomething().GetAwaiter() I figure, but I don't understand how to use it. When I try to run var doSomething = DoSomething();, DoSomething runs until the first await, but never continues and the Awaiter's GetResult() is never called.Berglund
The analog of GetEnumerator is GetAwaiter. The analog of { MoveNext and Current } is { IsCompleted, OnCompleted, and GetResult }. See Marc Gravell's blog: marcgravell.blogspot.com/2011/04/musings-on-async.html.Emmeram
Can you give a short example of calling an async and intercepting the awaitables and ContineWith()ing? The Gravell blog's attached code sample seems more complex than necessary for this supposedly simple case.Berglund
@uosɐſ fair enough; I also added a bit to explain "unreachable end point"Emmeram
This is a really great answer too. Thanks!Berglund

© 2022 - 2024 — McMap. All rights reserved.