-
Notifications
You must be signed in to change notification settings - Fork 1
Description
The actor model is, at it's most basic, a concurrency primitive in a similar vein as threads and future. However it seems that we always make a big todo about actor systems that we don't make with threads, futures, co-routines, etc.
It could be interesting to experiment with what it would look like to have short-lived, single-purpose actor systems. I believe these would be inherently local systems used or orchestrate potentially complex tasks. Imagine the following bit of (hypothetical code):
let result: Future<Result> = system.run<DataFetchActor>(FetchRequest {
service: "geo_ip.service",
continent: "NA",
department: "shoes",
})In this example, there are a few things happening:
- We're spawning an actor,
DataFetchActor, and providing a message to process - A
Future<Result>is created representing the response (anaskhere, maybe same as ask pattern support #19) - We're allowing data to return outside of the actor system
- The actor is closing down after handling the one request.
The reason this could be useful is that DataFetchActor may go on to spawn children. Perhaps it downloads quite a bit of data and does some data-processing. The logic within the actor may be complex, but we're using actors to organize that complexity.
Thought Process - It should be cheap and easy to spawn actor systems similar to how it's cheap and easy to spawn threads or futures. This lowers the barrier for use, opens up additional usage patterns, and allows for easier mix/match of concurrency patterns that can be common in large applications.
Metadata
Metadata
Assignees
Labels
Projects
Status