How can I edit a channel pipe to allow forking?

[ConnerP]

Hi, in relation to the discussion of parellel worker threads and promises here, I was wondering if I could modify a stream channel to allow wire forking because I like the ability to build "last item" and "abort" controls directly into the read/write nodes of the channels. There is a brief description of how to get started modifying channel code here but I cannot what determines wire forkability? Might someone have an idea how to go about that?

[wiebe@CARYA]

Are you talking about channel pipes (?), stream channels (?), or (not mentioned) channel wires (!), or streams or pipes? These are all related but different things, and it's really confusing (to me) if you mix the terms.

My guess is you mean channel wires... For clarity, I'll call them "channel wires" from now on.

Last time I checked, channel wires can be "forked" by default without any problems.

I have no idea what you mean by 'ability to build "last item" and "abort" controls directly into the read/write nodes of the channels'. That sounds like data you want to pass over the wire. That's what they are for, so it should not be a problem.

[ConnerP]

Honestly I don't see the major difference of anything you typed there. There is a difference between channel wires and pipes?

A standard Stream Channel ('subclass' of a pipe?) is only able to have one reader aka no forks in the channel wire. I want to edit it to enable multiple readers.

[altenbach]

What are you actually trying to achieve? Can you show us some simplified code?

QUOTE: "A Stream only allows for one writer and one reader– the wire is not allowed to fork."

See here

What do you mean by "edit"? Do you want to take the current channel code and modify it to your liking deep under the surface or are you looking for some simple change in configuration?

[billko]

---

@ConnerP wrote:

Honestly I don't see the major difference of anything you typed there. There is a difference between channel wires and pipes?

A standard Stream Channel ('subclass' of a pipe?) is only able to have one reader aka no forks in the channel wire. I want to edit it to enable multiple readers.

---

I think you want to use the replicate node to make a second copy of your data available; otherwise, use a message channel wire.  (It's in the LV Help File.)

[ConnerP]

---

@altenbach wrote:

What are you actually trying to achieve? Can you show us some simplified code?

QUOTE: "A Stream only allows for one writer and one reader– the wire is not allowed to fork."

See here

What do you mean by "edit"? Do you want to take the current channel code and modify it to your liking deep under the surface or are you looking for some simple change in configuration?

---

Yes I would like to modify it under the surface. There is a brief explanation about how to do this in the second link within my original post. However, I can't find how the internal code determines whether the channel wire can be split or not and I do not see a way around it.

[Bob_Schor]

I strongly recommend that you do not start "modifying Channel Wires under the surface".  Developing this feature (of which I am a Big Fan) took several years of hard work by some really top people at NI.  Even so, I believe that in making some "improvements" in LabVIEW 2017, they managed to cause a bug (which I demonstrated, unfortunately) and have issued a CAR -- maybe fixed in 2018?  2018 SP1?

Each Channel has a specific purpose, and has behaviors that suit that purpose.  For general Multiple Readers, Multiple Writers, the Messenger Channel fills the bill.  For simple One-to-One, the Stream Channel is what you want.

So what is your task?  What are you trying to "improve?

Bob Schor

[ConnerP]

If you would click on my first link you would know what I am trying to do.

[wiebe@CARYA]

---

@ConnerP wrote:

Honestly I don't see the major difference of anything you typed there. There is a difference between channel wires and pipes?

---

The difference between a channel wire and a pipe is that a pipe is a pipe and a channel wire is a channel wire. That's why things have a name, to distinguish between them. Especially in computer science, and even more when communicating about computer science though it makes sense to use the names of what you mean instead of something that might or might not be the same. If you mix channels, streams and pipes it makes things confusing.

Not being nit-picky here. I'm not the only one confused about what you want.

---

@ConnerP wrote:

A standard Stream Channel ('subclass' of a pipe?) is only able to have one reader aka no forks in the channel wire. I want to edit it to enable multiple readers.

---

Pretty sure pipes can have multiple readers.

So maybe you should not use a Stream Channel. Other channel wires can have multiple readers. But maybe you should not even use a channel wire.

A channel wire is just a group of wrapper VI's with a special wire. You might as well make a few VI's yourself that do exactly what you want. I'd put them in a class, and although the wire isn't exactly like a channel wire, it comes pretty close. But I still wouldn't call it a channel wire .

What's the benefit in hacking a channel wire?

[ConnerP]

In regards to the naming, I can only go off of the information that is available to me. The only clear thing is that "Channel Wires" is the all encompassing term for all types of async wires. In the second link within my original post, it states:

The templates that have "Pipe" in their name are non-forkable (except MsgPipe which I hope we rename in the future). All the others can be forked.

This indicates there are two classes of channels: pipes and "not pipes". All of the channel wire templates designed for data transfer (Stream and High Speed Stream) are descendents the more general pipe template. This means they are not forkable, which is the right way to handle things in 99% of the cases.

In the case which is discussed in the first link of my original post, I effectively want to utilize a worker thread pool for time critical computation. This involves dequeueing to multiple parallel loops. This can all be handled with a standard old queue setup as detailed in that thread. However, I have come to like the clarity of logic that channel wires offer in regards to passing loop controlling booleans, e.g. last item, abort, etc...

I had hoped there would be a reasonably simple way to modify a Stream or High Speed Stream template to allow forking, so that I could take advantage of the boolean controlling features.