@BOB Schor wrote:
It seems slightly arcane to me to create a queue just for this purpose.
Queues, notifiers, and events are the "correct" constructs to use for communicating between parallel threads on the same computer. Using local variables to convey information is usually a convenient hack. You can do it (and sometimes I do) but you might regret it later.
About a year ago and a half ago I was working on a large project that had been started by other developers. The main vi had about 5 parallel loops, each with their own state machine using a number of local variables and property nodes. Trying to step through code to debug it was nearly impossible, so I put 3 of the loops in sub vis. Needless to say, sub vis and local variables don't play well together. As I recall it took me a couple days to disentangle everything and implement a messaging system with the same functionality.
Lesson Learned: Every shortcut taken incurs some amount of "code debt" that will have to paid off in the future--with interest. As the debt grows (continuously using shortcuts) more effort is spent paying off interest (fighting the limitations of the shortcut) than paying down the principle (refactoring and improving the code) or saving for the future (killing bugs and adding new features.)
As a general rule all my local variables and fp property nodes go in the UI loop, and only in the UI loop. If another loop needs to update a fp value, it sends the new value to the UI loop in a message and the UI loop handles the actual updating. On the occasion where I do use local variable/prop nodes in other loops, I recognize it for what it is--an implementation shortcut that will probably have to be changed later.
@BOB Schor wrote:
Are there advantages of a queue over a local variable for stopping parallel loops?
In addition to the disadvantages Ravens listed and the limited ability to refactor code, there may be performance considerations. I know using fp property nodes requires an internal switch to the UI thread (not to be confused with the UI loop on the bd) which requires considerable overhead. I don't think local variables do, but I'm not sure. Regardless, sending data directly to the terminal is faster than using a local variable.
If you use a local variable wired directly to the stop terminal then you have less control over the clean up process. Sometimes a loop will have a fairly complex shut down process. If one step fails you might want the program to alert the operator and continue functioning. Once you exit the loop you can't go back. Continuing the program is no longer an option.
Sometimes loops have to be shut down in a particular order. Again, you can't control this very well using a local variable wired to a stop terminal, at least not without a gigantic flat sequence structure or error wires snaking back and forth.
Finally, usually there is some sort of information that needs to be transferred between loops. "Stop" is just one of those pieces of information. If you already have something in place for communication, why step outside that and use something else?
--------------
As far as the examples go, I'd view them as simplified code to illustrate how network streams work, not an example of how to build a robust application. Typically if one loop unexpectedly exits all the loops should exit. This safety valve helps prevent hung apps and unpredictable behavior. The examples I looked at don't have that behavior. (I don't expect them to either as that would unnecessarily complicate the code.)
