Actor Framework Discussions
Actor Principles, Complexity and Class Count
I have been studying actor programming best practices and reviewing the presentations Dave (aka: Daklu) has made on this topic. One area that I am having the most trouble with is the 'rule' that an actor should never be blocked. I interpret this as the message handler should execute messages quickly and we should not put code in the message execution that has an unknown amount of execution time. This seems simular to the rules around producer/consumer architecture where you have a UI producer event structure that you want to quickly process UI events and hand off any lenghy processes to the consumer. So this made sense to me at first.
But, the problem I run into is while the actor's message hander is the 'producer' in this scenario there is no 'consumer' in an Actor. So, I am left with either handing off the lenghty process to a 'helper loop' or to another actor. This is where the complexity problem arises.
Lets take the example of an actor that has an initialization process. This process consists of 3 steps. Each step requires accessing an external resource (device, file, database, whatever). The point is accessing the external resource will require an unknown amount of time to execute. So, my first inclination is this should not be done in the message execution but rather handed off to a child actor or helper loop. The second part of this example is each of the 3 steps is an action we may want to repeat individually after initialization. So, we need a means to start each action in the Actor and a means to tell the actor the action is complete. If we use a child actor, we need a means to perform the action in the child. This amounts to 9 messages.
And, by placing the lenghy processes in the message execution of the child actor, we are violating the same rule for the child that prompted us to move the actions outside of the parent message execution.
If, instead we use a helper loop and decide to not call it an 'actor', we still need the 6 messages in the parent actor to start and complete the actions. We then need to create a new message passing method (queue, user event, etc) for the parent actor to command the helper loop to execute each step. And since the helper loop normally resides on the same block diagram as the parent actor's message hander (running in parallel), we still prevent the actor from exiting completely if the helper loop is blocked for some reason when executing the lengthy process.
In my opinion, there does not seem to be much advantage to moving the lenghy process outside of the message execution in the parent actor. If you were to leave it there, 9 messages would be reduced to 3. The complexity of the application would be reduced and the ability to understand and debug it improved. The class count in your project would be reduced, thus reliving slowdown issues with the IDE. And in the end, there does not seem to be a way to satisfy the requirement of non-blocking since we can only move the blocking action down to a lower level.
I guess what I am asking is if this is worth it? What is the argument to justify the costs?
Lastly, I am curious about the best way to implement the multi-step process. Where do you put the logic to tell the system to proceed from Action A to Action B to Action C when you are performing the initilization vs only executing one Action when you are not performing initialization? Should it be within the Action Complete messages or should it return to the initialize message that uses state data to process each Action's completion and determine next steps? Should we pass information about how to report completion to the message that performs the Action? I want to make this flexible enough so I can apply this to several areas but I also do not want to make it any more complex than it needs to be.
Thanks for reading all that and for your feedback,
-John
Thants for the responses! I have been thinking about my specific situation in this context to see if any of your ideas will help. I am leaning toward eliminating the helper and performing the actions within the main (parent) actor message execution. These operations are required to setup my actor and they must be done in order at initialization. I also realized that while I may want to repeat some of the actions later (to re-load data from my data source), not all of the actions fit this catagory.
Also, I want to trap errors that occur within the actions and take appropriate steps. If they are separated from the main actor, that just complicates the interface because I need to communicate the error back instead of just the data.
I can still make these actions into separate messages within the parent, but I am leaning toward a different scheme for performing them. I am thinking of adding an init flag to the actor and having each message call the appropriate next message in the sequence if the flag is set. Once I get to the last action, I will clear the init flag. This way if I call an action and init is not set, it will perform the action, update the actor state data but not contine to the next action in the sequence. This seems like a cleaner way to do this type of operation. The one thing I do not like about this design is the need for each action message to know what action should follow when doing an init. It seems like it would be better to keep that information in one place instead. Any ideas or examples of how to do this cleaner?
I agree with the comments about the UI responsiveness. I use a simular process of handing UI updates to a helper event loop to do the display work. I also have the UI event loop send a message to the actor when the user takes an action.
As for command-pattern architectures, I am not sure I would have used it if I had known about the IDE issues. I like the elegant nature of the design but it has gotten to the point where I can only work on my code in sections in separate projects setup to limit the number of classes in memory at once. This does help with keeping things more modular (MVC style) however, so maybe that is not totally a bad thing. 
Good questions John. I'm glad you asked them because it helps me understand what I need to clarify in my presentation.
First, I need to point out the presentation I gave at the CLA Summit (and at last year's NI Week) is titled "Fundamentals of Actor Oriented Programming." It's intended to introduce people to actor oriented programming using concepts that are familiar to QSM/QMH programmers. Unfortunately there isn't enough time to dig into too many nitty gritty details like you are asking about.
You are correct that continuously pushing lengthy processes lower in the hierarchy doesn't gain you much of anything. ("It's turtles all the way down.") The real question is, what does "lengthy" mean? Like kegghead said, it's a relative term. I consider a process "lengthy" when it causes messages to stack up in the queue. (Stacked messages are, IMO, generally a bad thing.) If you have an actor you can guarantee will receive only one message every 10 minutes, there's no problem with having it execute a 9 minute process in its message handling loop.
In your example, the main actor (M) can receive requests to do A, B, or C, but it can also receive requests to do many other things, as well as receive information from other actors that affect how M (or any of M's subactors, S) handles those requests. By making a subactor (or helper loop) responsible for doing A, B, and C, you free up the message handling loop to handle all the other messages that may arrive while those lengthy processes are executing. Those processes take just as long in the subactor, but the subactor is responsible for fewer things and is (usually) receiving messages less frequently, so its message queue doesn't stack up while executing the process. Ultimately it comes down to managing the messages that are flowing to the loop that is executing the long process.
"In my opinion, there does not seem to be much advantage to moving the lenghy process outside of the message execution in the parent actor. If you were to leave it there, 9 messages would be reduced to 3. The complexity of the application would be reduced and the ability to understand and debug it improved."
On the surface 3 messages appears simpler than 9, but it really depends on the application and project requirements. If you have A, B, and C execute in the message handling loop you have two basic options:
1. Have each action enqueue the following action. In other words, A's last act is to enqueue ExecuteActionB, and B's last act is to enqueue ExecuteActionC. The disadvantage of this is you have embedded business logic in the independent actions. You can't execute A without also executing B and C.
2. Enqueue BeginActionA, BeginActionB, and BeginActionC messages all at once. If each action takes 10 seconds, you've just committed yourself to 30 seconds before that actor can respond to any other messages, like Exit. Maybe that's okay, maybe it isn't.
To take it a step further, suppose the actor just started initialization and the user did something that causes two BeginActionB and an additional BeginActionC messages to be sent to the actor, then changes his mind and tries to exit the application. Now the user has to wait 60 seconds for the app to quit.
How do you solve that problem? Priority messages? That *can* work, but it creates an entirely new set of issues and adds complexity. By pushing the lengthy process down to S and having M handle the sequencing you guarantee that the longest you will ever have to wait to do something new (like exit) is the duration of the single longest subprocess.
"The class count in your project would be reduced, thus reliving slowdown issues with the IDE."
Yeah, count that as another reason I prefer name-data messaging over command-pattern messaging. But you can't claim you weren't warned. 
"Where do you put the logic to tell the system to proceed from Action A to Action B to Action C when you are performing the initilization vs only executing one Action when you are not performing initialization? Should it be within the Action Complete messages or should it return to the initialize message that uses state data to process each Action's completion and determine next steps?"
I don't see any reason to go back to the Init message. One way to implement it is to create an IsInitializing flag in M. When it receives an action complete message from S it checks the flag. If the flag is true then it sends the next action in the sequence to S. When the sequence is complete M sets the flag to false. You'll have to decide what to do with other messages that arrive during the initialization process.
Jed394 wrote:
I have been using Daklu's MHL actor pattern using Lapdog.
Just as an FYI, I'm calling it "Agile Actors" now. Presumptuous? Perhaps.
Jed394 wrote:
What you give up in flexibility of expandable messages, i think you gain in debugging and general headaches, such as renaming messages or broken dynamic dispatch overrides.
I hope you mean relief from general headaches, not gain general headaches. 
Jed394 wrote:
I am curious how others approach hardware blocking.
There's not much you can do when your software is blocked by a hardware call other than wait. When I have an actor directly interacting with hardware, I'll typically put the hardware calls in a helper loop to prevent the MHL from stacking up. That allows my app to be as responsive as possible given the constraints of the hardware.
You *can* put the hardware calls directly in the MHL, but then your parent actor (assuming you are using a hierarchical design) has to be aware of the hardware actor's state and task progress to avoid stacking up the message queue. Really all you're doing is pushing that management responsibility up another level.
"Where do you put the logic to tell the system to proceed from Action A to Action B to Action C when you are performing the initilization vs only executing one Action when you are not performing initialization? Should it be within the Action Complete messages or should it return to the initialize message that uses state data to process each Action's completion and determine next steps?"
I don't see any reason to go back to the Init message. One way to implement it is to create an IsInitializing flag in M. When it receives an action complete message from S it checks the flag. If the flag is true then it sends the next action in the sequence to S. When the sequence is complete M sets the flag to false. You'll have to decide what to do with other messages that arrive during the initialization process.
It seems to me that if the Action Complete message that S sends to M needs to read the flag and then decide to execute the next step in the init sequence or not, that is ebedding the business logic across each Action Complete message. I was thinking of a different solution that would capture the logic in a single place. Perhaps having a central message that controls the sequence (like the init message) and then having the Action Complete Messages all call that. This way we could check the flag in the init message and decide what to do next (continue init or nothing if we are not in init mode). If I want to change the order or add a step, I only need to modify the init message. I may want to rename the init message, however.
This breaks the responsibilites down to this:
Init message sets the init flag, clears all the action complete flags and sends the Begin Action message for the first step.
Begin Action (M) clears the Action Complete Flag for that action (if not already cleared) and calls S to do the action.
S returns the data to M using the Action Complete message.
The Action Complete message sets the Action Complete Flag, stores the returned data and checks the init flag to see if it should call the Init message.
The Init message sees that the init flag is set and then checks each action complete flag to see what is done and what needs to be done next. It then either calls the next Begin Action message or if all actions are complete, clears the init flag.
Any messages that arrive durring this process can see if the data is valid for an action by testing the action's flag and can see if an init is being done to decide if they should continue or ignore the message.
I am sure Dave will pokes some holes in this now. 
So, poke away! I realise this is adding complexity. I think this situation is generic enough that we should be able to come up with a reusable design pattern here that can be applied to many applications and architectures, regardless if you use AF or AA or something else.
