Stall Data Flow should be a no-op in the event of an error

[croohcifer]

I'm a huge fan of the Stall Data Flow malleable VI except in the case that I have it wired on an error wire (my most common use case) and there's an error on the wire.  I generally trust and expect that VIs (especially those on the palettes) will no-op (with rare exceptions like close ref methods) and fail fast in the event of an error on the error in terminal.  I understand that this is kind of a unique case since the VI in question is malleable and doesn't have an actual error in terminal, but my guess is that most users:

1.  Wire this specific VIM on error wires most often

2.  Likely don't want the VI to stall in the event of an error

3.  Would prefer to see that error propagated as quickly as possible like most other VIs do

Thoughts?

[wiebe@CARYA]

I definitely feel the same way about not stalling on errors. But we can make our own .vims. This one would be fairly easy to make. 

[croohcifer]

Sure, and normally I would write my own workaround and not even post it here, but this case almost feels like a bug to me.  I'm mainly curious to get NI's perspective on a niche case like this.

[crossrulz]

See the discussion here: Darren's Occasional Nugget 01/05/2018 (introduction to Stall Data Flow)

Oh, and I am in favor of no waiting on an error.  I have an alteration of that VIM in that thread that would cover the requirement.

[AristosQueue (NI)]

How in the world could that node *not* wait on error? All nodes in LV execute only when all their inputs arrive at the node. You're asking for a node that would abandon that??? I don't see that happening.

[croohcifer]

I think you may have misunderstood what I wrote.  The wording is perhaps ambiguous.

I'm *not* saying that the VI should abandon data flow - i.e., if there is an error wire wired to the input, don't wait for that error on the wire to propagate to Stall Data Flow and instead just call the VI immediately.  I agree that would be nonsensical.

What I'm saying is that *if* you wire an error wire into the input node and *if* at runtime there is an error on the wire when Stall Data Flow is called, I want Stall Data Flow NOT to call Wait (ms).  Instead, I want it to no-op.  This would make its behavior consistent with basically all other VIs that have error terminals, including timing functions like the High Resolution Polling Wait.

Hopefully that's a clear explanation 🙂

[croohcifer]

JeffK's argument on the thread crossrulz linked to above is "Everyone can create malleable VIs so just create a variation of Stall that does exactly what you want.  I implemented the simplest version that works with a single pass-thru wire and has the simplest semantics.  I'm expecting people to design variations of Stall as well as lots of other useful vims I've never even thought of!"

With the greatest respect for JeffK, I disagree.  There are many NI-written VIs on the palettes that are open-source, and I don't see those VIs violating the principle of no-oping in the case of an error on the input terminal.  To take the most obvious example, the High Resolution Polling Wait is open-source and performs a near-identical function to Stall Data Flow, but it no-ops if there is an error on the input.  Why should Stall Data Flow be any different?  Just because it's a VIM?  I don't think that's a good reason to violate a best practice for passing errors expediently along the error chain.

Of course we can create our own code, and we do.  I just think something as ubiquitous as a wait with terminals to enforce data flow *shouldn't* be something every NI user has to recreate, maintain, and internally distribute.  It should be on the shipping palettes and operate in a manner consistent with other VIs. 

[AristosQueue (NI)]

croohcifer: I see your counterargument and raise you the 800-lb gorrilla of rejection notices. 🙂

See specifically the discussion about variations on Wait MS. The Stall Data Flow has the same behavior as Wait MS.

Related query: Why are you stalling "no error" anyway? That seems really odd.

[croohcifer]

AristosQueue:

I'm certainly not out to rehash the gorilla :).  I think my argument is distinct.

On the thread you linked to, you said: "When a node takes a refnum as input, it generally can generate at least one error: "refnum is invalid". It also generally needs serialization up against other nodes that use refnums (programs that use refnums rarely use just one). Neither of those necessarily applies to the Wait Ms node. It is frequently used along side pure dataflow code to control the rate of execution. It cannot generate errors of its own. In our opinion, that makes it a node that should not needlessly encourage serialization. Requring the sequence structure around the Wait primitive discourages its serialization to a degree that seems, in our observation, to be appropriate."

Essentially, you said that NI wouldn't want to put dataflow-enforcing terminals on a Wait function because it would encourage unnecessary serialization, but I think that's a false choice fallacy.  You can have both functions (one with and one without error wires), and since 2014 when you wrote that, NI has added the High Resolution Polling Wait AND the Stall Data Flow VIs, both of which do what you said you wouldn't do in 2014.  I'm really glad that your opinion changed because now I don't have to write those VIs myself and tell everyone in my company to use the ones I write and internally distribute!  Yay!  All I'm saying is that one of these NI-provided VIs (Polling) returns immediately if there's an error on error in.  The other (Stall) does not.  This is an inconsistency, and I don't understand the reason for not wanting to make the behavior the same between these and nearly ALL other LabVIEW VIs on the palettes:  fail fast and no-op in the event of having an error (i.e., the Status boolean in the error cluster is TRUE) at runtime.

I'm not understanding your question: "Why are you stalling "no error" anyway? That seems really odd."  Could you elaborate?  I'll be really clear about what I'm asking for.  This code should take ~ 1000 ms to execute:

This code should take as close as possible to 0 ms to execute:

Instead, the second screenshot takes ~1000 ms to execute.  If you replace Stall Data Flow with the High Resolution Polling Wait, it behaves exactly as I want and exactly like most other VIs on the palettes if there is an incoming error:  it propagates the error as quickly as possible and does not execute its core functionality.

I'm struggling to understand why some of NI R&D wants Stall Data Flow to break this paradigm.  (I say "some" because Darren agrees with me and has urged others to kudo this idea :P).  I'm completely willing to be convinced that it should stay as is, but so far I don't see a good argument.

[AristosQueue (NI)]

> High Resolution Polling Wait

This node *can* produce errors. Therefore it has error terminals. My opinion has not changed.

[croohcifer]

This node *can* produce errors. Therefore it has error terminals.

---

When you wire an error wire into Stall Data Flow.vim, the specific compiled instance also has error terminals (even though it can't produce an error).  Thus, in this scenario, I believe it should behave consistently with other regular VIs that have error terminals.

Let me ask a more targeted question:  I was always taught that code should bubble up an error as fast as possible, so I code with the mindset that if a VI has error terminals, it should propagate any incoming errors (i.e., status boolean = TRUE) as fast as possible regardless of whether the VI itself can contribute an error to the error chain.  I'm interpreting what you're saying as fundamentally disagreeing with this when it comes to Stall Data Flow, but I don't understand why.  Why would you not want your code to fail faster?  Is that not a best practice?