Actors are just objects. The difference from normal objects is how you communicate with them and how they are managed.
The only way to communicate with an actor is to post a message to its mailbox. If ActorA needs information from ActorB, it would post a message to ActorB's mailbox. The message would have ActorA's "return address". When ActorB processes the message, it will send the response as a new message to ActorA's mailbox. But maybe ActorA just has work for ActorB and doesn't need a response... no return address.
Actors operate independently of each other, so multiple actors are doing work at any given time. But internally they only process one message at a time (aka single-threaded). This eliminates a large class of issues normally associated with concurrency.
In most distributed actor systems (e.g. Erlang), actors are managed by Supervisors. Supervisors will create new actors, check on their health, and replace failed ones. In actor systems without separate supervision, actors are usually responsible for creating and managing other actors as needed. In essence, specific actors become supervisors in addition to other duties.
The Actor Model of Computation (btw, don't search for just "Actor Model") is most suitable for stateful processing. It can work but fits less precisely with stateless workloads. An example where I've seen it work well is when a large amount of data needs to be loaded per request with frequent requests. Instead, spawn an actor (per entity) to keep the state and handle the very rapid changes. Unload the actor when activity dies down. Persist the state when it unloads (and maybe on a timer).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Actors are just objects. The difference from normal objects is how you communicate with them and how they are managed.
The only way to communicate with an actor is to post a message to its mailbox. If ActorA needs information from ActorB, it would post a message to ActorB's mailbox. The message would have ActorA's "return address". When ActorB processes the message, it will send the response as a new message to ActorA's mailbox. But maybe ActorA just has work for ActorB and doesn't need a response... no return address.
Actors operate independently of each other, so multiple actors are doing work at any given time. But internally they only process one message at a time (aka single-threaded). This eliminates a large class of issues normally associated with concurrency.
In most distributed actor systems (e.g. Erlang), actors are managed by Supervisors. Supervisors will create new actors, check on their health, and replace failed ones. In actor systems without separate supervision, actors are usually responsible for creating and managing other actors as needed. In essence, specific actors become supervisors in addition to other duties.
The Actor Model of Computation (btw, don't search for just "Actor Model") is most suitable for stateful processing. It can work but fits less precisely with stateless workloads. An example where I've seen it work well is when a large amount of data needs to be loaded per request with frequent requests. Instead, spawn an actor (per entity) to keep the state and handle the very rapid changes. Unload the actor when activity dies down. Persist the state when it unloads (and maybe on a timer).