Notifier communication, exit program

[LennartM]

Perphaps more an item for in the feature request section.

What I like about notifiers is that you don't have to connect wires. Making the program less cluttered. But it seems that you do have to connect the error wire to the second notifier to stop the loop. In the example below both 'wait on notification' blocks receive the updated number. But when the notifier is released only the left loop is stopped. Why does the right loop generate any error?

[Blokk · Accepted solution]

The proper question is: "Why does the right loop NOT generate any error?", since you use the error generated to stop the left lower listener loop. The answer is that, you use NAMED notifier. Try your example without naming it, and skipping the second "Obtain Notifier", only using the Notifier wire.

I understand that you might want to use named Notifier, so you can get notifications in subVIs, or in dynamically called other VIs, only using the same name for the "Obtain Notifier". If so, you need to send not only a value with the Notifier, but a cluster. In the cluster you can send a STOP! command, more elegant way to stop loops than generating an error...

The situation is that, if you read the Help of the "Obtain Notifier":

"Use named notifiers to pass data between two sections of a block diagram or between two VIs. If you do not wire name, the function creates a new, unnamed notifier reference. If you wire name, the function first searches for an existing notifier with the same name and returns a new reference to the existing notifier."

So because you get a NEW reference, it will not become invalid when you kill the other Notifier reference, even if, their name is the same! That is why the right loop not stopping, it does not generate error. This is the reason, why you should also clean up after the second "Obtain Notifier", using a second "Release Notifier"!

So as I said, the solution is to send explicit STOP command, like below.

And I note, I would never use a Notifier to stop parallel loops, since it is a LOSSY communication! You have a chance that the stop command does not arrive. For important commands, I use Queues, Channels (lossless ones, like Streams), or Dynamic User Events!

Edit: of course, just for a kind of "tag" data communication (you wanna read the latest value), when you do not need real lossless comm, a Notifier is totally OK to use! But you might want to setup another comm line (Queue, Dynamic User Event, etc) for commands, like stopping loops...

[LennartM]

Thanks for the extensive reply! I wanted indeed to ask why is does not generate an error. 

Weird that they implemented it with a new reference.

The idea with a cluster is a good option. But  then you have to send a Boolean all time while only using it on exit. The idea of destroying the notifier (or queue ) to kill the loop would have been a more elegant solution.

[Blokk]

---

@LennartM wrote:

Thanks for the extensive reply! I wanted indeed to ask why is does not generate an error. 

Weird that they implemented it with a new reference.

The idea with a cluster is a good option. But  then you have to send a Boolean all time while only using it on exit. The idea of destroying the notifier (or queue ) to kill the loop would have been a more elegant solution.

---

That was just an example. You could also send a string or enum command, what to do, to the loops. And what is the problem sending an extra Boolean, or string, or whatever? Your PC has Megabytes of RAM 😉

And I would not call elegant technique to exit a loop by generating an error. What about proper error handling strategy in your application? You might get an error from another source in that loop. Yes, you can program around, and check for the error code whether it is an "Exit loop error" or not, but this extra work is more than just using an Enum/string/Boolean as a command to Stop a parallel loop.

[drjdpowell · Accepted solution]

Note: there is a "Force Destroy" input on the "Release Notifier" that will do what you originally wanted.

Also note: hiding wires to "reduce clutter" just means you have invisible clutter.

[Blokk]

---

@drjdpowell wrote:

Note: there is a "Force Destroy" input on the "Release Notifier" that will do what you originally wanted.

Also note: hiding wires to "reduce clutter" just means you have invisible clutter.

---

Good point, I just overlooked this option 🙂 But I keep my opinion: an explicit "Stop!" command is just nicer 🙂 Ok, or handling the error by the specific error code is still valid...

edit: but since the Notifier is lossy, I might say...hmm, maybe just better to force destroy it! 😄