Implementing Actor Model in C# 5 / Async CTP - f#

Question

In an Actor Model, the actors have some sort of message loop where messages are matched using e.g. pattern matching (depending on language ofc)
e.g. pseudo F#
let message_loop() =
let! message = receive_message() //sync receive message
match message with
| Foo(a,b) -> DoStuff(a,b)
| Bar(c) -> DoOtherStuff(c)
| _ -> error ("unknown message")
message_loop()
So pretty much, a message signature is matched and associated with some action to perform on the message content.
Is there any conceptual difference between this and calling actual methods?
e.g. if I would do the following in C# 5:
class MyActor
{
//message signature Foo(a,b)
public void Foo(int a,string b)
{
Act( () => DoStuff(a,b) );
}
//message signature Bar(c)
public void Bar(int c)
{
Act( () => DoOtherStuff(c));
}
// the rest is infrasturcture code, can be refactored into an Actor Base class
//this emulates the sync behavior of the above actor
//each action is pushed onto a queue
//and then processed synchronously by the message handler
private void Act(Action action)
{
actions.Post(action);
}
private BufferBlock<Action> actions = new BufferBlock<Action>();
//this needs max degreee of parallellism = 1
private ActionBlock<Action> messageHandler = new ....
}
This way, invoking a method on MyActor will result in an async message posted onto a message queue which only handles a single kind of message; an Action.
However, the behavor associated with the message is contained in the message itself (posted from the public method)
So would this be a considered a clean way to do actors in C# 5 / Async CTP?
The benefits would be that messages are simply defined as normal messages instead of creating awkward message DTO like classes.
So would this be enough to make it work?

Answer 1

There is a slight difference between Task-based asynchrony and MailboxProcessor. Mailbox processor will always end up in the same thread, similar to Winforms message loop. Task keeps a SynchronizationContext. This means the same behavior for Winforms and WPF, but you could end up on a different thread when working with a thread-pool.
Otherwise, and conceptually, looks right to me.

Answer 2

I would say your approach is reasonable.
It is actually a good practice to encapsulate an F# agent behind an interface, itself dispatching messages to the agent:
type IPrintText =
abstract Stop : unit -> unit
abstract Print : string -> unit
module Printer =
type private Message =
| PrintText of string
| Stop
let Start () =
let agent =
MailboxProcessor.Start (fun inbox ->
let rec loop () = async {
let! msg = inbox.Receive()
return!
match msg with
| PrintText text ->
printfn "%s" text
loop ()
| Stop -> async.Zero()
}
loop ())
{ new IPrintText with
member x.Stop () = agent.Post Stop
member x.Print text = agent.Post <| PrintText text }
let agent = Printer.Start ()
agent.Print "Test"
agent.Stop ()