Reply Msg.lvclass Send Message And Wait for Response.vi

[BrianGShea@NGC]

I've been creating more Messages that require replys and have noticed a difficulty.

The Send Message and Wait for Response.vi must be generic in it's nature so that it can be overiden. However, i think this VI should be a core VI that is called from the real Send Message and Wait for Response.vi

The Send Message and Wait for Response should not be part of the Reply Msg class. It should be created (from a template) and should call the Core vi. The variant returned by the core should be changed into the correct response type(s) as defined by the outputs of then VI receiving the message.

I think this could be easily scripted much like the Message maker does for standard on-way messages. Unfortuantly i lack the understanding of VI scripting to quickly prototype it.

So, i'm humbly asking, if this is not in the works for the next verion of the Message maker that it be included. Which base class to inherit from could be selected as a radio button on the UI. Or it could be automatically selected if the Message VI has indicators other than the class and error out.

Thanks

Brian Shea

[AristosQueue (NI)]

I am very reluctant to promote Reply Msg in any way. "Deadlock-causing demon spawn and harbinger of flawed architecture" needs to be fought, not aided. 😉

But, having gotten the obligatory Warning of Doom out of the way, let's talk bout it.

Yes, what you are asking for is possible. I think we would keep the existing method backward compatibility, but we might remove it from the palettes. No, I don't think anyone is working on it. I have been managing to talk most people out of using such messages as time goes by. If someone created the scripting for that, I wouldn't be opposed to including it, but I'm not working on it nor would I consider it a valualbe use of R&D time compared to other projects -- Reply Msgs are just too rare.

You can create a nice custom "Send XYZ.vi" for your reply messages by using Create SubVI around the existing Send & Wait VI. Is it as efficient as a custom job? No, but if you're just trying to solve ease-of-wiring, it's a fine solution.

You could also make your own template just by doing Save As on one child class and giving it a typedef that is the reply queue's data type.

My biggest problem with Reply Msg in the short run is that it interferes with the network layers of AF that we've been trying to add. There's no way that I know of to seemlessly make the reply work whether the receiving actor is on the same machine or on a remote machine. It's one more reason to shy away from those classes in my book. If someone can propose a way to build a reply mechanism that works in concert with the nested network actor code that I've posted to this community group, it would go a long way toward me not objecting to Reply Msgs being treated as second-class citizens (as opposed to the third- or fourth-class citizens that they are today!).

[Daklu]

BrianGShea@NTS wrote:

I've been creating more Messages that require replys and have noticed a difficulty.

I'll second what AQ said about Wait for Reply messages being the harbinger of flawed architecture.  If the inheritance tree is the first difficulty you've noticed with them, I guarantee it won't be the last.

I recommend spending a little time trying to figure out what it is about your design that is encouraging Wait for Reply messages.  Actor oriented programming is all about creating *asynchronous* processes.  Using Wait for Reply inserts sychronous dependencies in places where they normally should not exist.

[BrianGShea@NGC]

I agree with your Doom warning and have been actively coding around the chance that an Actor does not respond. I guess I needed the slap to set me straight. Thanks! I'm going to re-think my messaging and instead send a message to the actor to tell it to clean up then the actor can send a message to the storage manager to save its data. Rather than using the request/reply pattern.

I'm at the planning stage of a large AF project and so have been writing a lot of prototype code, so I have no issues throwing it away.

This Doom warning would be best served as a front panel note so others can understand the risk.

I think it would be best to not include this in the message maker so that it does not become a standard practice.

Thanks for the reply and keep up the good work!

[David_Staab]

BrianGShea@NTS wrote:

I think it would be best to not include this in the message maker so that it does not become a standard practice.

To borrow a phrase from the Python community, "We're all consenting adults here." Let's not make it harder for people to write code simply because we think they shouldn't normally want to write that code. There are valid use cases for everything that can be written, however arcane, and we should educate one another about what those cases are. For example,

BrianGShea@NTS wrote:

This Doom warning would be best served as a front panel note so others can understand the risk.

That's a good idea, and all (in my opinion) that needs to be done to give the designer a fair chance at success. Anything that makes the Reply Msg class harder to find, use, or maintain only serves to hurt the community of AF users.

[AristosQueue (NI)]

David Staab wrote:

Let's not make it harder for people to write code simply because we think they shouldn't normally want to write that code.

I fully agree with this. If someone makes it easier, I'm not going to get in the way. *I* just won't be making that easier. 😉

[munsmat]

One place that I'm interested in using a synchronous reply methodology is when actors represent physical pieces of hardware. If I send an "initialize" command to a hardware device, I actually care about receiving the "initialized" response before allowing any other commands be sent. I have several hardware devices that use some variant of command-response, and commands sent before the last response are ignored (and this behavior is likely not transparent to the end user). Would this be a valid use case for implementing the "Deadlock-causing demon spawn and harbinger of flawed architecture"?

[drjdpowell]

If you have actors representing hardware, then the hardware-actor can do synchronous command-response with the physical hardware, while queuing up commands until they can be sent.  Thus, other actors would not need to use synchronous reply messages with the hardware-actor.  And advantage of using a dedicated "actor front end" to physical hardware is that you can compensate for the limited comunication.