blocks|key|2000442|text|我要说的是有点没意思。模式解释器通常使用状态机实现call/cc，该状态机将本地状态捕获到堆上。这也正是C#+5.0+(或者更准确地说，C#+2.0的迭代器)所做的事情。他们确实实现了call/cc，他们提出的抽象非常优雅。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2000443|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Kinda pointless I'd say. Scheme interpreters often implement call/cc with a state machine that captures local state onto the heap. Which is exactly what C# 5.0 (or more correctly C# 2.0's iterator) does as well. They did implement call/cc, the abstraction they came up with is quite elegant.

blocks|key|1786699|text|原始答案：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1786700|根据我的理解，您的问题是“如果不是专门为基于任务的异步实现"await”，而是实现了更通用的call-with-current-+control控制流操作，会怎么样？“|1786701|好吧，首先让我们考虑一下"await“是做什么的。"await“接受类型为Task<T>的表达式，获取一个等待器，并使用当前的continuation调用该等待器：|offset|length|style|CODE|1786702|await+FooAsync()|code-block|syntax|javascript|1786703|变得更加有效|1786704|var+task+=+FooAsync();
var+awaiter+=+task.GetAwaiter();
awaiter.BeginAwait(somehow+get+the+current+continuation);|1786705|现在假设我们有一个运算符callcc，它将一个方法作为其参数，并使用当前的延续调用该方法。它看起来像这样：|1786706|var+task+=+FooAsync();
var+awaiter+=+task.GetAwaiter();
callcc+awaiter.BeginAwait;|1786707|换句话说：|1786708|await+FooAsync()|1786709|只不过是|1786710|callcc+FooAsync().GetAwaiter().BeginAwait;|1786711|这回答了你的问题吗？|1786712|1786713|更新#1：|1786714|正如评论者指出的那样，下面的答案假设了异步/等待功能的“技术预览”版本中的代码生成模式。我们实际上在功能的测试版中生成了略有不同的代码，尽管在逻辑上是相同的。目前的codegen类似于：|1786715|var+task+=+FooAsync();
var+awaiter+=+task.GetAwaiter();
if+(!awaiter.IsCompleted)
{
++++awaiter.OnCompleted(somehow+get+the+current+continuation);
++++//+control+now+returns+to+the+caller;+when+the+task+is+complete+control+resumes...
}
//+...+here:
result+=+awaiter.GetResult();
//+And+now+the+task+builder+for+the+current+method+is+updated+with+the+result.|1786716|请注意，这有点复杂，并且处理您正在“等待”已经计算出的结果的情况。如果你等待的结果实际上已经在内存中为你缓存了，那么就没有必要经历将控制权交给调用者的所有繁琐工作，并从你停止的地方重新开始。|1786717|因此，"await“和"+callcc”之间的联系并不像在预览版中那样简单，但很明显，我们本质上是在等待器的"OnCompleted“方法上做一个callcc。如果没有必要，我们就不做callcc。|1786718|1786719|更新#2：|1786720|就像这个答案|1786721|https://stackoverflow.com/a/9826822/88656|1786722|Timwi指出，call/cc和await的语义并不完全相同；“真正的”call/cc要求我们“捕获”方法的整个延续，包括它的整个调用堆栈，或者等效地将整个程序重写为延续传递样式。|1786723|"await“特性更像是一个”协作调用/cc“；continuation只捕获”当前的任务返回方法在等待时下一步要做什么？“如果任务返回方法的调用者要在任务完成后做一些有趣的事情，那么它可以自由地将其complete注册为任务的complete。|1786724|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|11|7|0|0|0|0|C|6|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|15|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|20|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|21|8|@$F|22|G|23|H|I]]|9|@]|A|$]]|$1|J|3|K|5|L|7|24|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|25|8|@]|9|@]|A|$]]|$1|Q|3|R|5|L|7|26|8|@]|9|@]|A|$M|N]]|$1|S|3|T|5|6|7|27|8|@$F|28|G|29|H|I]]|9|@]|A|$]]|$1|U|3|V|5|L|7|2A|8|@]|9|@]|A|$M|N]]|$1|W|3|X|5|6|7|2B|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|L|7|2C|8|@]|9|@]|A|$M|N]]|$1|10|3|11|5|6|7|2D|8|@]|9|@]|A|$]]|$1|12|3|13|5|L|7|2E|8|@]|9|@]|A|$M|N]]|$1|14|3|15|5|6|7|2F|8|@]|9|@]|A|$]]|$1|16|3|-4|5|6|7|2G|8|@]|9|@]|A|$]]|$1|17|3|18|5|6|7|2H|8|@]|9|@]|A|$]]|$1|19|3|1A|5|6|7|2I|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|L|7|2J|8|@]|9|@]|A|$M|N]]|$1|1D|3|1E|5|6|7|2K|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|6|7|2L|8|@]|9|@]|A|$]]|$1|1H|3|-4|5|6|7|2M|8|@]|9|@]|A|$]]|$1|1I|3|1J|5|6|7|2N|8|@]|9|@]|A|$]]|$1|1K|3|1L|5|6|7|2O|8|@]|9|@]|A|$]]|$1|1M|3|1N|5|6|7|2P|8|@]|9|@$F|2Q|G|2R|1|2S]]|A|$]]|$1|1O|3|1P|5|6|7|2T|8|@]|9|@]|A|$]]|$1|1Q|3|1R|5|6|7|2U|8|@]|9|@]|A|$]]|$1|1S|3|-4|5|6|7|2V|8|@]|9|@]|A|$]]]|1T|$1U|$5|1V|1W|1X|A|$1Y|1N]]]]

<h2>Original answer:</h2>

Your question, as I understand it, is "what if instead of implementing "await" specifically for task-based asynchrony, rather, the more general control flow operation of call-with-current-continuation had been implemented?"

Well, first of all let's think about what "await" does. "await" takes an expression of type <code>Task&lt;T&gt;</code>, obtains an awaiter, and calls the awaiter with the current continuation:

<pre><code>await FooAsync()
</code></pre>

becomes effectively

<pre><code>var task = FooAsync();
var awaiter = task.GetAwaiter();
awaiter.BeginAwait(somehow get the current continuation);
</code></pre>

Now suppose we had an operator <code>callcc</code> which takes as its argument a method, and calls the method with the current continuation. That would look like this:

<pre><code>var task = FooAsync();
var awaiter = task.GetAwaiter();
callcc awaiter.BeginAwait;
</code></pre>

In other words:

<pre><code>await FooAsync()
</code></pre>

is nothing more than 

<pre><code>callcc FooAsync().GetAwaiter().BeginAwait;
</code></pre>

Does that answer your question?

<hr>

<h2>Update #1:</h2>

As a commenter points out, the answer below assumes the code generation pattern from the "Technology Preview" version of the async/await feature. We actually generate slightly different code in the beta version of the feature, though logically it is the same. The present codegen is something like:

<pre><code>var task = FooAsync();
var awaiter = task.GetAwaiter();
if (!awaiter.IsCompleted)
{
 awaiter.OnCompleted(somehow get the current continuation);
 // control now returns to the caller; when the task is complete control resumes...
}
// ... here:
result = awaiter.GetResult();
// And now the task builder for the current method is updated with the result.
</code></pre>

Notice that this is somewhat more complicated, and handles the case where you are "awaiting" a result that has already been computed. There's no need to go through all the rigamarole of yielding control to the caller and picking up again where you left off if the result that you are waiting for is in fact already cached in memory for you right there. 

Thus the connection between "await" and "callcc" is not quite as straightforward as it was in the preview release, but it is still clear that we are essentially doing a callcc on the "OnCompleted" method of the awaiter. We just don't do the callcc if we don't have to.

<hr>

<h2>Update #2:</h2>

As this answer 

<a href="https://stackoverflow.com/a/9826822/88656">https://stackoverflow.com/a/9826822/88656</a>

from Timwi points out, the semantics of call/cc and await are not quite the same; a "true" call/cc requires either that we "capture" the entire continuation of a method including its whole call stack, or equivalently that the whole program be rewritten into continuation passing style.

The "await" feature is more like a "cooperative call/cc"; the continuation only captures "what is the current task-returning method about to do next at the point of the await?" If the caller of the task-returning method is going to do something interesting after the task is complete then it is free to sign up its continuation as the continuation of the task.

blocks|key|2000473|text|我不是延续方面的专家，但我将尝试解释async/await和call/cc之间的区别。当然，这个解释假设我理解call/cc和async/await，我不确定我是否理解。不管怎么说，这是……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2000474|使用C#+'async'，你告诉编译器生成特定方法的一个特殊版本，该方法理解如何将它的状态封装到堆数据结构中，这样它就可以“从实际堆栈中移除”，并在以后恢复。在异步上下文中，"await“类似于"call/cc”，因为它使用编译器生成的对象来封装状态，并离开“实际堆栈”，直到任务完成。但是，因为它是对异步方法的编译器重写，允许将状态封存起来，所以await只能在异步上下文中使用。|2000475|在第一类call/cc中，语言运行时生成所有代码，以便可以将当前的continuation封装到call-continuation+function中(使async关键字变得不必要)。call/cc仍然像await一样，导致当前延续状态(想想堆栈状态)被阻塞，并作为函数传递给被调用的函数。要做到这一点，一种方法是对所有函数调用使用堆框架，而不是“栈”框架。(有时称为“stackless”，如在“stackless+python”或许多方案实现中)另一种方法是在调用call/cc目标之前从“真实堆栈”中移除所有数据，并将其填充到堆数据结构中。|2000476|如果堆栈中混合了对外部函数(比如DllImport)的调用，可能会出现一些棘手的问题。我怀疑这就是他们使用async/await实现的原因。|2000477|http://www.madore.org/~david/computers/callcc.html|offset|length|2000478|2000479|因为在C#中，一个函数必须标记为"+async“才能使用这些机制，我想知道这个async关键字是否会成为一种病毒，传播到许多库中的许多函数中。如果发生这种情况。他们可能最终意识到他们应该在VM级实现一流的call/cc，而不是这种基于编译器重写的异步模型。只有时间能证明一切。但是，在当前C#环境的上下文中，它无疑是一个有用的工具。|2000480|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|0|0|1E|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@$J|10|K|11|1|12]]|A|$]]|$1|L|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|14|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|I]]]]

I'm no expert at continuations, but I'll take a stab at explaining the difference between async/await and call/cc. Of course this explanation assumes I understand call/cc and async/await, which I'm not sure I do. Nevertheless, here goes...

With C# 'async', you are telling the compiler to generate a special version of that specific method which understands how to bottle it's state into a heap-data-structure, so it can be "removed from the real stack" and resumed later. Within an async-context, "await" is then like "call/cc" in that it uses the compiler-generated objects to bottle up the state and get off the "real stack" until the task completes. However, because it's the compiler rewriting of an async-method that allows the state to be bottled up, await can only be used within an async context.

In first-class call/cc, the language runtime generates all code such that the current continuation can be bottled up into a call-continuation-function (making the async keyword unnecessary). call/cc still acts like await, causing the current-continuation state (think of the stack state) to be botled up and passed in as a function to the called-function. One way to do this is to use heap-frames for all function invocation, instead of 'stack' frames. (sometimes referred to as 'stackless', as in 'stackless python' or many scheme implementations) Another way is to remove all the data from the "real stack" and stuff it into a heap data-structure before calling the call/cc target. 

Some tricky issues can arise if there are calls to external functions (think DllImport) intermixed on the stack. I suspect this is the reason they went with the async/await implementation. 

<a href="http://www.madore.org/~david/computers/callcc.html" rel="nofollow">http://www.madore.org/~david/computers/callcc.html</a>

<hr>

Because in C#, a function must be marked as "async" in order to use these mechanics, I wonder if this async keyword will become a virus that spreads to lots of functions in lots of libraries. If this happens. they may eventually realize they should implement first-class call/cc at the VM level, instead of this compiler-rewriting based async model. Only time will tell. However, it's certainly a useful tool in the context of the current C# environment.

I've been following the new announcement regarding the new <code>async</code> feature that will be in c# 5.0. I have a basic understanding of continuation passing style and of the transformation the new c# compiler makes to code like this snippet from <a href="https://devblogs.microsoft.com/ericlippert/wp-login.php?redirect_to=/ericlippert/asynchrony-in-c-5-part-one" rel="nofollow noreferrer">Eric Lippert's post</a>:
<pre><code>async void ArchiveDocuments(List&lt;Url&gt; urls)
{
 Task archive = null;
 for(int i = 0; i &lt; urls.Count; ++i)
 {
 var document = await FetchAsync(urls[i]);
 if (archive != null)
 await archive;
 archive = ArchiveAsync(document);
 }
}
</code></pre>
I know that some languages implement continuations natively, via call-with-current-continuation (<code>callcc</code>), but I don't really understand how that works or what it does exactly.
So here's the question: if Anders et al. had decided to bite the bullet and just implement <code>callcc</code> in c# 5.0 instead of the <code>async</code>/<code>await</code> special case, what would the above snippet look like?

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

数据结构

编译器

解释器

我一直在关注关于c# 5.0中新的async特性的新公告。我对延续传递方式和新的c#编译器对中的代码片段所做的转换有了基本的了解async void ArchiveDocuments(List<Url> urls){ Task archive = null; for(int i = 0; i < urls.Coun...

问如何使用call/cc实现c# 5.0中的新异步功能？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何使用call/cc实现c# 5.0中的新异步功能？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何使用call/cc实现c# 5.0中的新异步功能？
EN