Async F # против CCR - PullRequest
       26

Async F # против CCR

2 голосов
/ 07 мая 2010

После прочтения о CCR: http://www.infoq.com/news/2008/12/CCR У меня создается впечатление, что он работает почти так же, как блоки F # async?

Вы передаете port.Receive и port.Test, чтобы сделать то же самое, что и "let!".

Это правильно? И есть ли какие-либо преимущества в CCR, которые вы не получаете с F # async?

1 Ответ

4 голосов
/ 07 мая 2010

Пример в упомянутой статье действительно выглядит как let! из асинхронных рабочих процессов.В общем, ключевое слово yield return в C # позволяет кодировать шаблоны, похожие на выражения вычисления F # (странным образом, потому что он был разработан для создания перечислителей):

  • Это также используется AsyncEnumerator , который (IMHO) проще, чем CCR, и немного ближе к асинхронным рабочим процессам F #
  • Я написал статью , которая объясняет это сходство более подробно.

Я думаю, что ключевым отличием между асинхронными рабочими процессами CCR и F # является то, что CCR также включает библиотеки для параллельной передачи сообщений.См., Например, эту статью - он использует класс Port (вы можете отправлять сообщения в порты) и Arbiter.Receive, который является примитивом, который позволяет вам ждать сообщения от Port.

В F # вы можете использовать MailboxProcessor для реализации того же шаблона передачи сообщений, но это не встроенная часть асинхронных рабочих процессов F # - MailboxProcessor реализовано с использованием асинхронногорабочие процессы.

В итоге : я думаю, что асинхронные рабочие процессы F # проще и концептуально яснее.Однако CCR и асинхронные рабочие процессы вместе с MailboxProcessor реализуют примерно один и тот же шаблон программирования.

...