When does it make sense to use an actor vs a simple event loop?

[ilmoi]

I just finished this and this tutorials on tokio actors and am left with this impression:

1. It's a lot more work to build an actor system than to use a simple event loop (for x in y { tokio::spawn(...) })
2. The only use case seems to be sharing a resource that can't be shared through other means (ie no copy, no arc/mutex) - in which case it's delegated to an actor who owns it and receives messages from tasks that need it

Are there other use-cases when one might want to use actors over a simple event loop? If so, what are they?

And am I right in thinking that if it can be done with an event loop, that's the preferred way since it's simpler?

[Darksonn]

Here's another use-case for actors: If you have a server with many open connections that need to communicate with each other, then wrapping each connection in an actor is usually a good strategy. In my article that you linked, I mention this in the following paragraph:

For example, if you are implementing a chat server, you may spawn a task for each connection, and a master task that routes chat messages between the other tasks. This is useful because the master task can avoid having to deal with network IO, and the connection tasks can focus exclusively on dealing with network IO.

I usually link to this project as an example of this. It goes through various features of the article:

• It has an actor for every connection. This actor actually has two tasks internally, one for sending and one for receiving, but they share the same handle.
• It has an actor that handles routing/forwarding of messages between the connection actors (it's a chatroom).
• Each connection actor has a handle to the router actor (the handle can be cloned). The router actor has a HashMap containing handles to all connection actors.
• There is no issue with deadlocked cycles because router → connection uses try_send.
• It uses a simple loop for accepting connections. This loop is essentially the basic event loop that you mention, except that tokio::spawn is replaced with spawning an actor, then sending the new actor's handle to the router actor.

---

Of course, you should not use actors just because you like actors. They are a design pattern that is sometimes useful. If you can write the code in a simple way without actors, don't use actors. Web servers usually don't need actors, because there is little communication between different connections to the server.

To conclude, use actors when the alternative is more complicated.

[ilmoi]

thanks Alice, this is helpful, especially the telnet project