The Actor model can be used to isolate a volatile state from the outside world. When you have a mutable state (for example, a global registry of identifiers assigned to several parallel processes), you can wrap this mutable state inside an actor and force clients to communicate with the Actor via message passing. Thus, only the actor accesses the mutable state directly, and, as you say, the client message queue must be read and processed one by one. It is important that the messages are unchanged.
To avoid queue filling, it is important that message processing ( react , receive , etc.) is react as short as possible. Long-term tasks must be transferred to another player:
1. Actor A receives a message M from sender S 2. A spawns a new actor C 3. A sends (S, f(M)) to C 4. In parallel: 4a. A starts processing the next message. 4b. C does the long-running or dangerous (IO) task, When finished, sends the result to S, and C terminates.
Some alternatives in the process:
So, to repeat, the actor is multithreaded to the point that several clients can send him several messages from different streams, and it is guaranteed that the actor will process all these messages in turn (although the order may be subject to various not too strict restrictions).
Please note that although Actor react code can be executed in different threads , at one given point in time it is executed on only one given thread (you can imagine that the actor goes from thread to thread as the scheduler considers necessary, but this is a technical detail) . Note. Internal state still does not require synchronization, as an action occurs between message processing . - before semantics .
Parallelism is achieved through the simultaneous use of several actors, usually forming a supervisor hierarchy or balancing workload .
Please note that if all you need is parallel / asynchronous computing, but you don’t have or cannot get rid of the global state, Future better compiled and a more understandable concept.