Our vision is that send/expect should work according to the default distributed-process semantics, but one ought to be allowed to vary the semantics of channel-based communication (as opposed to actor-based) according to what is relevant to the application. E.g. an application ought to be able to give up reliability for better latency/throughput on a channel-by-channel basis.
That pretty exciting. I will have to put aside some time to tryout Cloud
Haskell on top of your ZeroMQ layer. I would love to see a simple example
of how this would work with different reliability settings in a ping-pong
example.
On Mon, Mar 31, 2014 at 1:34 PM, Edsko de Vries
Hi Mathieu,
That sounds great! It's great to see that the redesign of Cloud Haskell with a pluggable Network.Transport layer is in fact being used. Good stuff!
Edsko
-- You received this message because you are subscribed to the Google Groups "parallel-haskell" group. To unsubscribe from this group and stop receiving emails from it, send an email to parallel-haskell+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
-- Patrick Wheeler Patrick.John.Wheeler@gmail.com Patrick.J.Wheeler@rice.edu Patrick.Wheeler@colorado.edu