-
Notifications
You must be signed in to change notification settings - Fork 419
Initial implementation of ActorContext and the #spawn function #48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@lucasallan What do you think of this as the first step in a new actor framework? It provides the same capabilities as the current |
I like it :) You mentioned auto restart, what is your plan for supervisors, do you plan to have an erlang style supervisor hierarchy ? |
@schmurfy We already have a functionally complete implementation of Erlang's Supervisor that supports supervision trees and a Runnable mixin so that anyone can create a supervisor-compatible class. (The code could use some refactoring but I'm holding off on that until we work through the new I plan on keeping supervision a part of the new The simple case that I've built in this PR doesn't use |
I was thinking about something similar to what Erlang does: process A spawn processes B and C, if B and C dies then A dies too and its parent respawn A which will respawn B and C. The "let it ail" philosophy is one of the things I really like about Erlang. |
Initial implementation of ActorContext and the #spawn function
Update test suite to Minitest 5
This PR implements the simplest case of the new actor framework as discussed in issue #36. It deprecates the previous
Actor
base class and replaces it with theActorContext
mixin module. The only implemented factory method isspawn
which creates a single instance of the actor class, wraps it in anActorRef
object, and restarts the actor thread should it crash.Creating an actor is done simply by including
ActorContext
and implementing a#receive
method that takes with the signaturedef receive(*msg)
. It receives a message of zero or more arguments and returns the result of message processing.Actors which mix in the
ActorContext
module have a new lifecycle:on_start
,on_reset
, andon_shutdown
. The first and the last are each called once. Theon_reset
method is called every time the actor is reset. Actor resetting is a larger topic which will eventually be written about in the wiki. The lifecycle that triggerson_start
is controlled by several factory options including:abort_on_exception
,:reset_on_error
, and:rescue_exception
.This implementation reduces the number of message passing methods from four down to two:
post
andpost!
. Theforward
method has been deprecated and will not likely return. The originalpost
method, which returned a boolean value, has been deprecated. It was based on a Scala method which returnedvoid
. Ruby does not have void functions so there was no value in having bothpost
andpost?
(the latter of which returned a future).The
post
method now always returns a future object (specifically, anIVar
). Additionally thepost
method can be given a block which will act as a callback on message completion. The block parameters are the same as for observation. The difference is that observers are notified every time a message is processed whereas thepost
callback only applies to the given message.The
post!
method works the way it did in the previousActor
implementation. It blocks for the given number of seconds and bubbles raised errors.An example: