Channel Wires vs. Actor Framework?

[Kyle203]

The Channel Wires feature in LabVIEW 2016 looks like a good way to handle asynchronous communication.  What types of situations is it better to use Actor Framework rather than Channel Wires? 

[AristosQueue (NI)]

I was asked this question several times over NIWeek. I have limited ability to answer... I think I'm too close to the problem.

To me, it's like asking "I have a pry bar and a screwdriver... what types of situations should I use the pry bar?" I mean, yes, there is some overlap in that both can be used to open a paint can, but if you have easy access to both tools, the correct one seems intuitive. It gets weirder in that I've rewritten the AF to use channel wires*, which would then make the answer "use both together", so they aren't even entirely orthogonal for me. Channels are one form of connective tissue. Actors are the things the tissue connects.

I'm kind of hoping someone in the community can give a useful answer to this question. Every time I've tried to write up "you use this for X and that for Y", my answer gets pretty mushy, even though it seems pretty clear to me.

--------------------------------------------

* privately, as a test project, using a prototype of LV 2015 that no longer builds. No, I don't have the code to share around for discussion. It was more of a "could I do this" than a "I think this is a good idea" project.

[drjdpowell]

Isn't a big difference static versus dynamic architecture?  I haven't used Channels yet, but I see them as a great way to set up static communication channels between "helper" loops inside an actor**.  Currently I do such loops with queues and/or notifiers.  But I'm not sure how Channels substitute for the dynamic launching and shutdown of actors.

**Note I use a different "actor" design than the AF, so you'll have to double check if my insight works with the AF.

[jlokanis]

I generally implement user events for my message handler to helper loop comm.  At actor launch I setup the events and store their refs in the actor's private data.  Message Do sends data to the helper via the user event and the helper sends data to the message handler (to store state data, etc) via normal messages (send to self).

Shutdown has its own event kept in isolation (not in the private data).  When message loop exits, the next node on the BD fires the shutdown event to stop the helper loop.  Helper loop can only ask message handler to exit, it can't stop itself except from the shutdown event.  Keeps things clean and prevents anyone outside from accidentally shutting down one loop without closing the other.

Not sure how I could make this work better with channel wires.  Maybe if there was a generic way to implement a channel wire interface on the message handler that could work for all actors.  But I think the channel wires are more case specific so a generic solution might not be feasible.  Also not sure about a class based solution where actors could override the communication process with more specific needs.  I have not waded into the channel wires much yet so maybe there is a way to do this.  Perhaps this is something AQ could offer some thoughts on?

[drjdpowell]

jlokanis wrote:

I generally implement user events for my message handler to helper loop comm. 

Your helper loop is also a message handler, just with messages called "events", some of which can come from the UI.  I doubt Channels will help with that.  My helper loops are generally not message handlers, as they are usually ocupied with something that prevents them being available to wait on messages.  An example would be a TCP Listener, a loop which is just waiting for new TCP connections. 

[jlokanis]

I see your point.  But in my case, the comm path is private between the message handler and the helper loop so the helper cannot respond to messages from other actor unless they first call the message handler which can in turn fire an event.

90% of my helper loops are implementing a UI so they are busy dealing with events generated by the user most of the time.

I do use other loop structures for things like listening on TCP ports.  In those cases I pass a local DVR to the loop so the message handler can tell it to exit.  Someime queues are used to send data out.  Perhaps this is an area where the channel wires could be useful.

[AristosQueue (NI)]

I'll just leave this image here. Let me know if that would be useful to have.

[AristosQueue (NI)]

[AristosQueue (NI)]

[bsvare]

Just so I can imagine it well, with this new feature, you can effectively hide all the event registration code into a channel?

So this image you posted earlier today:

can be effectively be abc constant into a channel into the event case. So, removing 75% of the block diagram. I mean, it's not like you need to have while loops around the channel writer or event structure.

Channels are really getting cool!