Best practice for altering state of actor from its helper loop?

[drjdpowell]

Seems to me a lot can be done just with better documentation.  Is there an reason the current documentation is written to never directly reference the existence of an event queue?

[AristosQueue (NI)]

> Is there an reason the current documentation is written to never directly reference the existence of an event queue?

Yes. Discussing an event "queue" was baffling to too many users. Some went so far as to try to wire in the queue palette somehow. It's a behind-the-scenes implementation detail whose exposure would in theory provide clarity but in practice appears to make the situation worse for many [possibly majority] of users. It's hard to judge that, especially back in the early 2000s when we were evaluating the documentation. In my personal experience in recent years, the deeper explanation is generally only helpful when I explain it one-on-one. I think the difference has to do with the tendency I observe for people to skim shipping documentation but to read deeper on forum posts addressed to them or when presented in person.

[t.kendall]

@AristosQueue I feel personally attacked 😉

[drjdpowell]

---

@AristosQueue (NI) wrote:

> Is there an reason the current documentation is written to never directly reference the existence of an event queue?

Discussing an event "queue" was baffling to too many users. 

---

"Event Buffer" or some other name, then?  Surely anything is less confusing than the "Event Registration" referred to in the documentation, which sounds like a list of Events to record, rather than an a actual queue buffer of Events waiting for handling.

Wait, is it because Americans "stand in a line" rather than "queue", so don't know what a queue is?  

Hey, I finally found one reference in the help to events being queued:

https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/dynamic_register_event/

"After registration, LabVIEW queues events as they occur until an Event structure executes to handle the events."

But it's only in one place and hard to find.

[OneOfTheDans]

I have to agree with drjdpowell - User Events have always felt to me like a mystical feature of LabVIEW with lots of caveats that need to be memorized. Now that I know about the Event Queue, they make sense (thank you for the explanation @drjdpowell!)

Queues, Notifiers, and User Events are all similar communication tools, and their pipes/buffers are all passed by-reference. The datatypes are: "queue", "notifier", and "event registration refnum". One of these is not like the others... changing the name to "listener" (or anything) could help.

The input terminal of "Register for Events" could also include the default behavior "listener (create new)", which would give even more clarity about the node's convenient double-duty.

[OneOfTheDans]

---

@OneOfTheDans wrote:

The datatypes are: "queue", "notifier", and "event registration refnum"

---

I see now that the datatypes are actually "Queue Refnum", "Notifier Refnum", and "Event Registration Refnum". But the terminal labels for Queue and Notifier drop the "Refnum". "Listener" may still be clearer than "Event Registration".

[hassanizhar]

A best practice for altering the state of an actor from its helper loop would be to use message passing to communicate between the helper and the actor. This involves the helper sending a message to the actor containing the desired state change, and the actor applying that change to its internal state. This approach allows the actor to maintain control over its own state and ensures that the helper is not modifying the state directly. Additionally, using message passing makes it easy to reason about the behavior of the actor, as all state changes must be explicitly communicated via messages.

Another important thing is to make sure that the internal state of the actor is protected from concurrent access by multiple helper, for that you can use a feature provided by actor model frameworks (such as Akka.NET) that is called "Ask pattern" or "Tell pattern". This allow actor to only process one message at a time which will be safe from concurrent access.

[justACS]

---

@hassanizhar wrote:

A best practice for altering the state of an actor from its helper loop would be to use message passing to communicate between the helper and the actor.

---

Small quibble:  the helper loop is a part of the actor; it is more correct to say that the actor passes a message from its helper loop to its message handling loop (the contents of the parent actor core).

---

Another important thing is to make sure that the internal state of the actor is protected from concurrent access by multiple helper, for that you can use a feature provided by actor model frameworks (such as Akka.NET) that is called "Ask pattern" or "Tell pattern". This allow actor to only process one message at a time which will be safe from concurrent access.

---

Helper loops don't access the internal state of their actors; they only pass messages to the message handling loop.  The message handling loop executes messages sequentially and completely, so there can be no concurrent access from helper loops. You don't have to do anything special.