实现会改变等待的行为吗？

Question

Await 关键字与可等待类型一起使用（.NET 带有现有的两种此类类型，Task 和 Task<T>）。但是，您可以编写自己的可等待类型。

msdn blog post 声明：

你可以想到下面的代码：

await FooAsync();
RestOfMethod();

本质上与此相似：

var t = FooAsync();
var currentContext = SynchronizationContext.Current;
t.ContinueWith(delegate
{
    if (currentContext == null)
        RestOfMethod();
    else
        currentContext.Post(delegate { RestOfMethod(); }, null);
}, TaskScheduler.Current);

上面的（伪）代码是否遵循可等待类型的实现（例如Task），或者可能只是编译器处理任何可等待类型的方式await 关键字的右侧？

在下面的 cmets 部分，有一篇文章解释了 TaskScheduler 和 SynchronizationContext 之间的区别。

主要区别在于 SynchronizationContext 是一个通用的 与委托合作的机制，而 TaskScheduler 是 特定于并迎合任务（您可以获得一个 TaskScheduler 包装一个 SynchronizationContext 使用 TaskScheduler.FromCurrentSynchronizationContext）。这就是为什么 等待任务将两者都考虑在内，首先检查 SynchronizationContext（作为大多数 UI 中更通用的机制） 框架支持），然后回退到 TaskScheduler。 等待不同类型的对象可能会选择首先使用 SynchronizationContext，然后回退到其他一些机制 特定于该特定类型。

如果我正确理解最后一句话，这意味着我可以将我想要的任何委托放入continueWith 方法中（我的意思是上面代码示例中的t.ContinueWith 调用），即修改await 在与我的自定义等待对象。

以防万一您想了解更多： http://blogs.msdn.com/b/pfxteam/archive/2009/09/22/9898090.aspx

Answer 1

上面的（伪）代码是从 awaitable 类型（如 Task）的实现中继承而来，还是只是编译器处理 await 关键字右侧的任何 awaitable 类型的方式？

伪代码确实来自具体的任务实现。但它的存在只是为了帮助您了解它的工作原理，因为它与延续相似。

编译器生成的实际代码差别很大，它没有考虑实际的等待类型。它所做的只是寻找一个GetAwaiter 方法，该方法返回一个具有IsCompleted、GetResult、OnCompleted 的等待者。可等待的实现是捕获或不捕获SynchronizationContext.Current（或完全执行其他操作）的实现。

你可以看到实际代码here。

即完全修改 await 与我的自定义可等待对象一起使用时的工作方式。

只要对你有意义，你可以做任何你想做的事。您甚至可以使用扩展方法使内置类型可等待。例如这段代码：

public static Awaiter GetAwaiter(this string s)
{
    throw new NotImplementedException();
}
public abstract class Awaiter : INotifyCompletion
{
    public abstract bool IsCompleted { get; }
    public abstract void GetResult();
    public abstract void OnCompleted(Action continuation);
}

将使您能够编译await "bar";。它当然会在运行时失败，但编译器不知道。