Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

How to get a feedback from an actor (working or stopping)?

I am playing with the AF.

I have this:

1) actor with UI (some buttons - used to send messages to this actor or other actors - and a string indicator, just to print events)

2) 2 nested actors, I start them inside the UI actor's core

  • "Test-Inputs-Actor", has methods like: testInput1, testinput2, testInput3
  • "Test-Outputs-Actor", has methods like: testOut1, testOut2, testOut3

3) I have the messages objects created by the scaffolding.

So my questions are:

1) In UI actor core, I just can send messages to actors, inside the event handler. Simple. I get it. That will ultimately trigger the actor method vi.

I can also send a batch of messages from UI actor to his nested, via their enqueuers

INSIDE the nested actor's method VI, I can SEND BACK messages to the parent actor.

Is this a normal behaviour? it is async of course, because at the end of the day I am just enqueuing messages in the pipes of paralles QMH.

I mean: is it correct to say that actor must communicate only via messages (using the "send msg xxx.vi") ?

2) Let's say I wanna stop the main UI actor.

Click stop (or whatever)

I send "send normal stop msg" to myself

This will trigger the "send normal stop" to all my nested actors.

How can I get a feedback from them? by overriding "Handle last ack core"? where? should I override this VI in my UI actor? If yes, then how to find which nested sent the last ack?

thanks

0 Kudos
Message 1 of 11
(6,232 Views)

Ironman_ wrote:

I mean: is it correct to say that actor must communicate only via messages (using the "send msg xxx.vi") ?

Pretty much, yes.

2) Let's say I wanna stop the main UI actor.

Click stop (or whatever)

I send "send normal stop msg" to myself

This will trigger the "send normal stop" to all my nested actors.

How can I get a feedback from them? by overriding "Handle last ack core"? where? should I override this VI in my UI actor? If yes, then how to find which nested sent the last ack?

Yes, handle last ack is the way to be notified that a nested actor has stopped, and to do something about it.  You should override it in the calling Actor, assuming that is where you will handle it.  The Read Caller-to-Actor Enqueuer function can be used within your override to determine which Actor stopped (the enqueuer provides a unique identifier).

Cheers,

Matt Pollock
National Instruments
0 Kudos
Message 2 of 11
(6,016 Views)

how can I distinguish NestedActor1 from NestedActor2 ?

I call "Read Caller-to-Actor Enqueuer", so I have this enqueuer (which is invalid soon).

Ahhh should I include the nested actor enqueuer INSIDE the caller acotr private data (cluster) ??

and then use the "==" compare?

0 Kudos
Message 3 of 11
(6,016 Views)

would it be possible to see some examples of how to use the Handle Last Ack Core.vi override please?

0 Kudos
Message 4 of 11
(6,016 Views)

Try giving the shipping example a look.  There are Handle Last Ack overrides in there to help the coffee shop manage the display of actors when those actors exit.  And yes, you can use the Equals or Search 1D array functions to compare the returned Actor enqueuer to what you hold onto in your caller.

(Just search for Actor Framework in the Example Finder, you'll see the Actor Framework Fundamentals project in there)

Cheers,

Matt Pollock
National Instruments
0 Kudos
Message 5 of 11
(6,016 Views)

where else could the Last Ack be handled if not only in the calling actor? i guess that is really what i had in mind when i asked my previous question.

0 Kudos
Message 6 of 11
(6,016 Views)

Scenario: A calls B, B calls C, and C shuts down due to an error.

By default, assuming no overrides of Handle Last Ack or Handle Error, the error that shut down C would be sent up to B, which would shut it down and send it up to A, which would also shut down.

You might do your handling at the A level and let B shut down.

Basically, you handle it at a higher layer in the calling hierarchy, but not necessarily the immediate caller.

Cheers,

Matt Pollock
National Instruments
0 Kudos
Message 7 of 11
(6,016 Views)

oh i see, yes, thank you.

0 Kudos
Message 8 of 11
(6,016 Views)

The coffeeshop example is way much complicated. It's a mess. Really doesn't help novice.

So what we got here is

  • doc sparse
  • insufficient examples. basically one is too basic, one is too complicated.
  • there is no example with actual NI hardware in the middle
  • missings scenarios: deal with synchrnous things, deal with blocking calls, waiting answer. Simply put: asynch everywhere is just plain wrong, it can't be done, you can't model everything with an asynch QMH.
  • the AF course is not available via internet, forcing people to move even beyond their own country. this is total nonsense in 2016
0 Kudos
Message 9 of 11
(6,016 Views)

@Ironman_ wrote:
Simply put: asynch everywhere is just plain wrong, it can't be done, you can't model everything with an asynch QMH.

The actor model originates in 1973 and works in many places far beyond LabVIEW quite successfully. There are entire languages that are async everywhere... see Erlang for a major example. It gained traction first in FPGA where everything can proceed in paralell. It languished on the desktop while we had predominantly single-threaded single CPUs. The async-everywhere approach gains power the more parallel processing is used in the system, and modern CPU architectures and more distributed network code mean that you're going to be getting a lot more architectures like the AF, not fewer.

 

You CAN model everything, right down to the Add primitives, as a QMH. Modeling is not the same as implementing, and actually implementing everything down to the Add primitive as a QMH is wasteful, but at some resolution, the model and the implementation do converge. AF is targeted at applications that are operating at that level of complexity. Those applications are becomming more and more common.

 

> Really doesn't help novice.

 

So... what would help you? The tutorials provided have helped many novices, but different people learn in different ways. What resources have you looked at already? We have sample projects, online examples, white papers, videos. I assume you've already reviewed the sample projects that ship with LabVIEW and the documentation that is part of those projects. Check out the Documentation and Learning Tools section for a list of some of them (there's more than are listed there... I can't keep up with all the ones that users and other NI folks have created).

 

You are correct that the getting started materials generally eschew actual hardware. The AF is a software framework. Any single piece of hardware you choose to use should be used by a single actor... one actor may use multiple pieces of hardware, but it should be the only one using that hardware (anyone else who needs the hardware should send a message to that one actor and let it do the work). We don't generally have examples with actual hardware because it really doesn't matter what hardware you choose to use. There are advanced use cases where a hardware refnum can be passed around among actors, but those are generally outside the realm of the novice projects.

 

The AF is a significant architecture with several moving parts. It is solving one of the hardest issues in computer programming: concurrent operations. That isn't something you just run with on Day One, which is why this community exists: to provide the mentoring and hand-holding needed to get a first-timer up and running. If you have specific questions, please ask, but just throwing stones doesn't help anyone else find resources that fit your learning approach.

Message 10 of 11
(6,012 Views)