LabVIEW Channel Wires
VI which works on a channel input will freeze if writer goes idle
A variation of the Pipe Write and Read endpoints have abort in and out terminals. Sending abort in will cause it to appear on the output of every endpoint.
AristosQueue wrote:
Mads: Try this channel that does not ship with LV 2015:
https://decibel.ni.com/content/docs/DOC-42942
See what you think.
Not bad.
I like the timeout and abort functionality (obviously).
One thing that queues lack is an in-built mechanism to signal the consumer that the producer has stopped, *without* having to force destroy the queue (and similarily, tell the producer that there are no consumers anymore (access to the internal number of obtained and open references could be a solution there; a number of subscribers...). That means that if you want the queue to be emptied by the consumer before it is terminated you have to make the producer monitor the queue state after its final insert, and only force destroy the queue once it sees that the queue has been emptied.That is not a big obstacle (so it could be a viable solutionf or channels too), but it does mean that there is no in-built (in other words - standardized and "free") solution to the issue.
So you could add functionality to give the consumer(s) in-sight into the state of the producer *without* cutting access to the elements remaining in the queue. In other words; instead of a force destroy that cuts access to those elements, you have a separate output (or a warning on the error state) that tells the consumer(s) that the producer side has finished.
I cannot see a picture in the proposition post from Jeff (was it lost, or is it somewhere else?), but from the following comments about extra iterations etc. I guess the issue you are discussing is how do you combine/disciminate between the event of an abort signal with a new value event(?).
Let's say that the producer has set the queue up for destruction, but there is no new value. The consumer side will then execute, but they might have more values to process still... How do you differentiate between an "abort only" trigger, and a value *and* abort? - If a consumer is still processing data from a producer that has destroyed the queue they could get a warning flag while reading the elements they have queued up (the warning/node could indicate the number of elements left as well perhaps), and then when they reach the end the warning turns into an error / termination complete on each iteration. If it is a goal that the consumer does not need to iterate a last time to figure out that the queue/channel is now fully terminated, it would need to use/get the number of elements and warning output.
I'm rambling a bit here so I'll let you clarify before I continue 
