Stopping multiple helper loops with one user event

[Waltteri]

I'm trying to learn Actor Framework and how I should handle some actions in the actor core.

So the picture tells what I'm asking, is there some reason I shouldn't do as it is shown in the picture, stopping "multiple" loops with one event? Unregistering the event should probably be done after both loops have stopped, but is there something else completely wrong?

I saw this on some other post and know that it's not the way to do it:

Thanks.

[OneOfTheDans]

I think what you showed is fine. I usually tailor the helper loop's stop mechanism to the helper loop. For example, if my helper loop is an event handler, I'd stop it with a user event fired in Stop Core. If my helper loop is a queue or notifier, I'd destroy them in Stop Core and shut down the helper loop when the queue/notifier becomes invalid. If don't have queues/notifiers, and I don't want to deal with PITA User Events, I will just wire a Front Panel boolean to the stop terminal, and "push" the button by-reference in Stop Core.

[Craig_]

Only one of your helper loops will stop!

You need one register for events function per event structure: https://zone.ni.com/reference/en-XX/help/371361R-01/glang/register_events/

"When using dynamic registration, make sure you have a Register For Events function for each Event structure."

[Waltteri]

Well, they both stopped when I tested.

[Taggart]

Craig's right. You need two too separate registrations. Only one of those loops should have gotten the event, unless you fired it twice.

That it worked? I have no idea why unless you fired it twice. It shouldn't have. One loop should have hung.

[Waltteri]

So this is the way to go?

No matter how many loops I added to the previous version, they all stopped.

I have Labview 2017 if that has anything to do with this.

[BertMcMahan]

Yeah that's the way to go. I seem to have read somewhere that multiple event handlers per registration is "undefined" behavior. I think the message could get seen by both loops or it could be seen by only one, and it's not set which is which. I've tried to nail down the exact behavior for multiple loops with one registration but couldn't figure out a specific pattern.

[Craig_]

The register for events function creates a queue of the input user events that are then de-queued by the event structures, so if you branch that wire to multiple event structures they race to de-queue the event, and only one of them can get it 🙂 (EDIT: see below for more clarification, they may both get it, but not always!)

[Craig_]

You can also use the event inspector window to get a direct debug view of the events!

https://zone.ni.com/reference/en-XX/help/371361R-01/lvdialog/event_inspectorwindow/

[BertMcMahan]

---

@Craig_ wrote:

The register for events function creates a queue of the input user events that are then de-queued by the event structures, so if you branch that wire to multiple event structures they race to de-queue the event, and only one of them can get it 🙂

---

I know that's the "expected" behavior, but it does not work that way in practice.

For example:

Run that code, click "Send", observe that both Loop 1 and Loop 2 indicators sometimes change together, but not always. Hammer on the Send button and you will see the two numbers increment together, but sometimes one of them doesn't see the event.

Granted I'm a little low on sleep right now so I could've made a dumb not-enough-coffee mistake in my example code lol, but I've tried this once or twice before with "weird" results. You'd think it would act like a queue but it seems to duplicate some events.