Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Error case in actor methods that should be called by message (style question)?

Hi folks,

 

I have a small question about the error case in actor methods. I usually maintain a virtual folder of "top level" methods that can (should, have to) be called by a message.

 

If want to create a method drom dynamic or static dispatch template I always get an vi with the error case case structure.

 

Since "error in" is always "no error" the error case is unreachable code for those methods and - in my opinion - can be removed. It should be removed since I have to avoid unreachable code. Is there some scenario where it makes sense to override handle error without stopping the actor and not clearing the error?

 

What I am doing at the moment is to create a static od dynamic dispatch mehod and remove the case structure before I start to implement the method.

 

Am I right and if yes, is there a way to create such a method without error case structure?

 

Thanks in advance

 

0 Kudos
Message 1 of 17
(4,017 Views)

One thought might be:  Do you think you would ever call those vis without it coming from a message?  I do that sometimes where I want a "batch" approach. Say I have 3 individual methods that each correspond to a message.  Then I have a 4th method, call it batch, that just simply calls all 3 of the other methods and it has its own message.  In that case would you care about an upstream error? maybe.. maybe not...

 

As far as creating a method without the error structure, I'm pretty sure all of those vis come from templates and you could likely edit the template to remove it. Search the forums, I'm sure I've seen posts about it before.  You might want to search for the LabVIEW Class project provider... 

 

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
Message 2 of 17
(4,012 Views)

You aren't restricted to calling just a single actor method in a message Do.vi.  You can call multiple methods or have other code.  And a different developer may be writing that Do.vi, so the error in may be used in future.

Message 3 of 17
(4,004 Views)

Thank you for your replies!

 

Calling the same actor method by message and directly does not seem good style (my question was about style) to me. If there is a message implemented I would rather send the message instead of calling the method directly. This should be always possible while the actor is alive and I have an error handling between to messages. If I call from "stop actor.vi" I have no error and therefore I do not need the error case inside the method. 

 

Calling more than one method in a do.vi seems also not very good style to me. I do not want intelligent messages, in my opinion the coding should be done within the actor and not within the message (which is another class). There is no reason, whi I should not have a method which calls two messages or does to vi calls.

 

The first option seems even better to me, because I check for errors between the vi calls. (I also increase the number of messages, but I do not care, since I use very small actors with a very limited number of possible tasks).

 

Maybe vi scripting is a good way to generate a (static/dynamic) dispatch method vi without error case.

 

 

0 Kudos
Message 4 of 17
(3,981 Views)

As perhaps not so explicitly detailed above, the reason for wanting more than one VI in the same message is to prevent interruption between messages in a 'batch' style. (You can create 'Batch Msg' classes too, but these can be a bit more frustrating to use in my opinion)

 

The idea here is that even if you send two (or more) messages directly after one another (even for example from inside the Actor which will handle the messages, using the output of Read Self-Enqueuer.vi), there's no guarantee that someone else didn't enqueue a message in between these two messages.

 

If you have completely stateless messages (as perhaps you should, but it's sometimes difficult (impossible?) to achieve) then this isn't a problem. However, as the parentheses suggest, this might not be the situation you find yourself in. When your messages are called in some sequence, to prevent race conditions you must create the sequence either in a single Do.vi (i.e, within one message) or by using the Batch Msg class (or as the/a parent class).


GCentral
0 Kudos
Message 5 of 17
(3,974 Views)

You should not be able to create a race condition for an actor by calling messages in the wrong order. When I send an message to an actor I know nothing about the implementation or the data it uses internally. Otherwise you couple actors, and the main advantage (to me) of the actor model is gone.

 

If the order of execution plays a role for some vis you should not create messages for them.

 

But even for this case I do not have to have the coding in the do.vi of the message. I can quickly create a method that combines the methods I would call in the do.vi. I can take care about errors there, and I have full access to the actors private data. For this method, I can create a message, which is equivalent to one, that calls two (or more) methods in the do.vi.

 

0 Kudos
Message 6 of 17
(3,959 Views)

@mthimm wrote:

Calling the same actor method by message and directly does not seem good style (my question was about style) to me. If there is a message implemented I would rather send the message instead of calling the method directly. 

 


No, this is completely legitimate.  Messages are for sending data between actors (mostly).  An actor can choose to respond to a message by calling one of its own methods, inside the method invoked by the message.  That method call is just part of the actors response, and you would do so to guarantee that the action happens before the actor processes a new message.

 

Now, the actor may choose to send itself a message.  In that case, the actor is explicitly allowing for the possibility of responding to another message first.  But that is a design choice on the part of the developer.  Actors have state, and there are often valid reasons why doing an action immediately, rather than sending yourself a message, is the way to go.

 

My favorite example is when the actor gets a message to do an operation, and calculates that it has to stop as a result of that operation.  The actor can send itself a Stop message, but that means it will handle every message that's already in its enqueuer before it does.  If what you want is for that actor to stop right now, and not handle those messages, then you don't send yourself a stop message, you just wire Error 43 out the error wire (the stop message doesn't target a method; if it did, it would just pass Error 43 out on the error wire).  So it all depends on the behavior you want.



 

Message 7 of 17
(3,946 Views)

@mthimm wrote:

 

If the order of execution plays a role for some vis you should not create messages for them.

 


I would certainly be impressed if I came across a complex application, with stateful hardware and ordinary human Users, that managed to do that.   Doubly impressed if I thought it wasn't way overcomplicated or difficult to understand.  I doubt the typical AF application satisfies this high bar.

0 Kudos
Message 8 of 17
(3,937 Views)

I am not convinced and I do not find this completely legitimate. But at least it is possible to call an actor method directly or by message if there is a message for that method. To me this is still bad style.

 

There is a priority queue for dealing with higher priority tasks. Lower priority messages wait until all higher priority messages are  processed. If you to avoid interference by other normal priority messages you can increase the priority of your message.

 

To me an actor should be always accessible. You override accessibility by an direct call. You can do this, but in my opinion you shouldn't. 

 

In a queued state machine (or queued message handler) you do not have the possibility to call a case of your case structure directly.

 

I like the idea to put code 43 on the error output. But you do not do a direct call by doing this.  In addition I would not do this. You can send an emergency stop or an normal/emergency stop instead. Actors should stop if and only if the get a stop message.

 

 

0 Kudos
Message 9 of 17
(3,924 Views)

@drjdpowell wrote:

@mthimm wrote:

 

If the order of execution plays a role for some vis you should not create messages for them.

 


I would certainly be impressed if I came across a complex application, with stateful hardware and ordinary human Users, that managed to do that.   Doubly impressed if I thought it wasn't way overcomplicated or difficult to understand.  I doubt the typical AF application satisfies this high bar.


Sorry for my bad accept-as-solution-click and sorry that my previous argument was so unclear.

 

To clarify, we were talking about interference by messages from other senders. If I put messages into my queue in a certain order, it is still guaranteed that they are executed in that order. Thus the order of execution plays certainly an important role to me. What I have meant was: If my caller sends message A1 and I send message B1 and B2 to myself, the order of execution can be (A1, B1, B2), (B1, A1, B2) or (B1, B2, A1), but never (B2, A1, B1). 

 

You can get messages only from yourself, your caller or your subactors. Since subactors are used to delegate tasks or responsibilty they should be independent from messages by myself and my caller.

 

Do you agree, that messages called by actors should be atomic transactions? I have the feeling, that I block my actor uneccessarily if I do a direct call.

 

My initial post was about the error case provided by the static/dynamic dispatch template. If you use an error case there you check in each call if no error is an error. This in my opinion is unnessecary. I doubt, that this is optimized by the compiler.

 

0 Kudos
Message 10 of 17
(3,919 Views)