Async F # vs. CCR Rahmen

Question

Nach der Lektüre über CCR: http://www.infoq.com/news/ 2008/12 / CCR Ich den Eindruck, dass es so ziemlich genau die gleiche Funktion wie F # Asynchron-Blöcke?

Sie liefern port.Receive und port.Test, um das gleiche wie „lassen!“ Zu tun.

Ist das richtig? Und gibt es irgendwelche Vorteile in CCR, dass Sie nicht mit F # async bekommen?

Answer 1

Das Beispiel in dem Artikel, den Sie wirklich erwähnt sieht genauso aus wie let! von asynchronen Workflows. Im Allgemeinen macht das yield return Schlüsselwort in C # möglich, es zu kodieren Mustern ähnlich wie F # Berechnung der Ausdrücke (in einer seltsamen Art und Weise, denn es ist für die Erstellung von Aufzählungen entworfen wurde):

• Dies wird auch von AsyncEnumerator , das ist (IMHO ) einfacher als CCR und ein bisschen näher an F # asynchronen Workflows
• Ich schrieb Artikel , die diese similartiy in mehr Einzelheiten erläutert.

Ich denke, dass der entscheidende Unterschied zwischen CCR und F # asynchroner Workflows ist, dass CCR enthält auch Bibliotheken für Message-Passing Gleichzeitigkeit. Siehe zum Beispiel dieser Artikel - es Port Klasse verwendet (Sie können senden Nachrichten-Ports) und Arbiter.Receive, die eine primitive, die Sie für Nachrichten von Port warten können.

In F # können Sie MailboxProcessor für die Durchführung des gleichen Message-Passing-Kommunikationsmuster verwenden, aber dies ist kein integrierter Bestandteil von F # asynchronen Workflows -. MailboxProcessor implementiert ist mit asynchronen Workflows

Zusammenfassend : Ich denke, dass F # asynchrone Abläufe einfacher und konzeptionell klarer. Allerdings CCR und asynchroner Workflows zusammen mit MailboxProcessor implementieren etwa dem gleichen Programmiermuster.