VI which works on a channel input will freeze if writer goes idle

[Mads]

In the example above the subVI that gets the channel wire as an input will run and get updates asyncronously, but if the while loop of the caller is stopped the subVI will just freeze. Is that intended behaviour?

I would expect it to continue running with the last known value as the output, and perhaps have an error output telling us that no one is writing to the channel anymore...

[Dragis]

The current implementation of a Tag Read (which I believe is what is in your image) will block until a new value is written. Once the Write is deactivated the Read will then wait forever. Use the Read Immediate if you want the last value written to be returned.

[AristosQueue (NI)]

Mads wrote:

and perhaps have an error output telling us that no one is writing to the channel anymore...

You have to send a signal that no one is writing to the channel any more. It might be that the producer has just gone off to do something else and will be recalled in a couple minutes. We've got a couple programs we've written around here where the producer loop generates some data then goes and services some request then comes back and generates some more data. The subVI that actually hosts the Write node isn't always the active running VI, but the channel user needs to signal that.

Take a look at the high-speed queue implementation that I posted to the forums... that channel has the back channel for letting the other end know that the front end is no longer producing data.

[Mads]

The behaviour does not just apply to Tag Read, it also applies at least to accumulator and buffer, but anyway:

The reader of a tag will wait indefinitely for the writer to produce new data yes. That seems a bit risky. It would have been nice to have an in-built way to timeout the read, or at least force a termination of the channel from the writer side (making all readers aware of the fact that there will be no more data, please handle this gracefully).

As it is now each developer will need to make his own safe mechanism to signal the readers prior to a stop - and make sure that all readers have indeed stopped their read loops before the writer allows itself to stop.

[Dragis]

Mads wrote:

The behaviour does not just apply to Tag Read, it also applies at least to accumulator and buffer, but anyway:

That's correct. In fact, most of the channel protocols are blocking by default and provide immediate and timed reads and writes for cases where that behavior is undesired.

Mads wrote:

The reader of a tag will wait indefinitely for the writer to produce new data yes. That seems a bit risky. It would have been nice to have an in-built way to timeout the read, or at least force a termination of the channel from the writer side (making all readers aware of the fact that there will be no more data, please handle this gracefully).

As it is now each developer will need to make his own safe mechanism to signal the readers prior to a stop - and make sure that all readers have indeed stopped their read loops before the writer allows itself to stop.

You may find the sentinel methods useful in cases where you want graceful shutdown of your application. Then sentinel token is written with the last data value. The reader can inspect the sentinel and stop processing once the final data value is written.

However, not all channels currently support the sentinel endpoints.

[AristosQueue (NI)]

Mads wrote:

As it is now each developer will need to make his own safe mechanism to signal the readers prior to a stop - and make sure that all readers have indeed stopped their read loops before the writer allows itself to stop.

Exactly the same problem faces any code that is doing cross-process communication. I don't see channels as a good vehicle to change that calculus at all. There's too much enviornmental for LV to automatically derive "this exit of the nearest loop means the transmission is done" vs "this exit of the nearest loop means the transmission is going to [possibly] restart". In fact, I think it falls afoul of the Turing Halting Problem -- no amount of mechanical analysis can ever decide whether the loop is going to restart if there's even a single conditional structure involved in the chain. So the developer is going to have to do something to raise that signal, just as they do today with queues/notifiers/events/etc.

Do you have a specific proposal for containing that behavior in the channels such that LV could automatically raise that signal?

[Mads]

This reminds me a bit on why I prefer queues over user events in some cases; I can choose to force destroy a queue. The producer's enqueue and consumer's dequeue event will then return immediately with an error, even if the timeout was set to infinite. Any subsequent actions on the queue will also return an error (unless someone recreates it).

Depending on my goal I can then let the consumer shut down as well gracefully, wait for the queue to be recreated (by re-running the obtain function with create set to false), or recreate the queue then and there.

So GUI-wise in this case you could for example have a destroy boolean input going into the channel writer node (or a destroy node that can be connected to the channel wire), and an error output or alive/dead boolean output on the read. Then let the readers return if the writer has been destroyed.

PS. These and other features of queues are the reasons I'm playing around with this little thing too: "MultiQ" (the name could be more accurate yes...) - a queue based alternative to pub-sub solutions based on User Events.

[AristosQueue (NI)]

Mads: Try this channel that does not ship with LV 2015:

https://decibel.ni.com/content/docs/DOC-42942

See what you think.

[AristosQueue (NI)]

I just added some images to the other channel thread that may be elucidating.

[AristosQueue (NI)]

JeffK is putting together a picture of the other way of doing a consumer-side stop. That'll be posted soon.