开发者

Async F# vs. CCR framework

开发者 https://www.devze.com 2022-12-30 01:27 出处:网络
After reading about CCR : http://www.infoq.com/news/2008/12/CCR I get the impression that it does pretty much exactly the same as F# asy开发者_开发知识库nc blocks?

After reading about CCR : http://www.infoq.com/news/2008/12/CCR I get the impression that it does pretty much exactly the same as F# asy开发者_开发知识库nc blocks?

You yield port.Receive and port.Test in order to do the same as "let!".

Is this correct? And are there any benefits in CCR that you don't get with F# async?


The example in the article you mentioned really looks just like let! from asynchronous workflows. In general, the yield return keyword in C# makes it possible to encode patterns similar to F# computation expressions (in a weird way, because it was designed for creating enumerators):

  • This is also used by AsyncEnumerator, which is (IMHO) simpler than CCR and a bit closer to F# asynchronous workflows
  • I wrote an article that explains this similartiy in more details.

I think that the key difference between CCR and F# asynchronous workflows is that CCR also includes libraries for message-passing concurrency. See for example this article - it uses Port class (you can send messages to ports) and Arbiter.Receive, which is a primitive that allows you to wait for messages from Port.

In F#, you can use MailboxProcessor for implementing the same message-passing communication pattern, but this isn't a built-in part of F# asynchronous workflows - MailboxProcessor is implemented using asynchronous workflows.

In summary: I think that F# asynchronous workflows are simpler and conceptually clearer. However, CCR and asynchronous workflows together with MailboxProcessor implement roughly the same programming pattern.

0

精彩评论

暂无评论...
验证码 换一张
取 消