That definition of an Actor actually seems a little restrictive. It certainly doesn't handle Erlang-style actors (or I believe Scala-style actors). In my experience, an actor is something that:
- Sends and receives messages (each actor has a mailbox)
- Shares no mutable memory with other actors
- Is scheduled based on the whims of the runtime. An actor could be given its own thread, but it is more likely that several actors participate in co-operative multithreading in a single thread, or maybe even participate in pre-emptive multithreading.
But fundamentally, an actor is a free-running chunk of code that can receive messages from its environment and can send messages back out to its environment.
Actors are used any time that you need lots (and lots) of stateful little processes. Networking is a common use case, because you don't want to allocate a whole thread to each connection. You want something lighter-weight, so you allocate an actor to each connection, and then schedule the actors on a smaller pool of threads. But networking is certainly not the only use of an actors.
In Erlang, an actor is a function. The function probably tail-calls itself (so it's basically an infinite loop), and it probably has a clean way to self-terminate (the infinite loop has a "break" condition). The loop typically waits for a message from the system, processes it, and then sends out messages to the rest of the system. The Erlang OTP library has some abstractions that eliminate the need to even write the loop, so an OTP actor is implemented as a set of callbacks. In that way, an OTP actor looks a lot like an object.