Proposing a change to Launch Actor.vi: No more required caller input?

[Daklu]

MattP wrote:

Video linked in the article from LV R & D developer (one of the most coherent explanations I've seen):

http://www.eyesonvis.com/blog/Viewlets/VIRefs/eyesonvis_vireferences_viewlet_swf .html

That's a pretty good link.  I discovered some subtleties I hadn't realized previously.  On slide 10 Christina mentions that Labview will abort the vi after Close Reference is called.

However, when I tested it using this code the called vi (Beep) continued running until I closed the front panel of this vi.

I often use the property node for getting a path to a vi, since it's more robust against moving things around in the file system.  Turns out the static reference throws a wrench into the expected behavior for dynamically called vis.  It makes more sense to me now but it took me a few minutes to figure it out.

[drjdpowell]

Staying on the original thread subject I like "Launch Root Actor".  Expresses the tree structure, and the fact that each actor tree will have one root.  Avoids confusion of being "callerless" when it is actually called (just by code that is not itself an actor). 

Also, stick with "enqueuer" as the implications it makes are both intended and significant.  Though I'm with tst in disliking the "Caller-to-Actor" verbiage, as it has poor readability for me.

I'm also struck by the problems of picking meaningful name analogies by the different baggage people have.  AQ mentions that "actors" and "objects" are seen as "antithetical" to each other by many and so he doesn't want to use "reference" as terminology.  Yet to me (who is not aware of this) it seems that actors and objects are clearly very closely related, and the "enqueuer" clearly used to "refer" to an Actor.  In my own actor-like framework, I used terminology from the "Observer pattern", something I had just recently read about, but then I found that this terminology implies things to both AQ and daklu that I did not intend, and was thus confusing. 

[drjdpowell]

On one the tangents:

Daklu wrote:

I discovered some subtleties I hadn't realized previously. 

The complexities of dynamicl launching are why I like to use the method (as is used in the AF) of having the framework code handle dynamic launching, with functionality added by some other method such as dynamic dispatch.  That way, all dynamic calling is done in a single place in a single (well thought-out and tested) way. 

I also never let dynamically called VI shutdown in the uncontrolled fashion of letting the VI reference die with the Caller; instead I let the death of some other reference trigger controlled shutdown.

[drjdpowell]

AristosQueue wrote:

drjdpowell wrote:

As the sender of a message, I don't care how it gets there.

I agree that you do not care *how* it gets there. I believe you do (despite protestations) care about *when*. After studying many of these applications and listening to many of you describe the functionality of your applications, I began to realize that the vast majority relied upon the ordering unconsciously, even when they consciously said they were aware that events might happen out of order.

I would say I have two forms of communication (using my "Messenging" framework).  One where the sender is commanding the receiver, where the sender does often depend on the order, and another is where the receiver is requesting notification of published information from the sender.  In the former case, it is usually one actor commanding its own callee, and "enqueuing" commands makes sense.  In the latter case, which often involves requesting the information from multiple senders, it doesn't mean much to say the sender is "enqueuing" messages.   If the receiver requires ordering then it needs to setup the mechanism.  In the paradigm behind my framework, the publisher of information is not responsible for its use; the requestor of the information is.  Actually, this requestor is often a third party (usually the Caller of both sender and receiver) so one often has the situation that neither sender nor receiver is responsible for communication.

[SteenSchmidt]

Daklu wrote:

SteenSchmidt wrote:

And if you can act on messages in any order, that's indistinguishable from messages arriving in any order.

This is incorrect. [pointing out the different histories in the two cases]...

Copy that. You're of course correct. Lot's of prioritization depends on history. So I buy into the premise that you're (almost) never interested in allowing out-of-order message reception in an actor. But I maintain that an actor should keep the right to out-of-order execution. Is that frowned upon in AF?

You do get that I'm not high school champ in AF, right? . But I am working on understanding the premise behind AF, so as to make a qualified decision when to embark on using it. Until now we've always rolled our own frameworks.

Cheers,

Steen

[Daklu]

SteenSchmidt wrote:
But I maintain that an actor should keep the right to out-of-order execution. Is that frowned upon in AF?

Nope, not at all.  Actor autonomy--meaning the actor decides what it should do (within the scope of its responsibility) when it receives a message--is a fundamental principle of actor-oriented programming.  That's why messages are also referred to as "requests."  The actor reserves the right to do what the message asks, or postpone the request for a later time, or ignore it altogether.

SteenSchmidt wrote:

You do get that I'm not high school champ in AF, right? .

Me neither.    Labview is way too big for anyone to be an expert in everything.  You don't have to look very hard to find one of my posts where I've said something wrong or misunderstood how something works.  (*cough* dynamic calls earlier in this thread *cough*)

[AristosQueue (NI)]

SteenSchmidt wrote:

But I maintain that an actor should keep the right to out-of-order execution. Is that frowned upon in AF?

That's fine to do. So long as the receiver is consciously storing up and then optimizing execution order, that's its right. The only objection I have is to actor implementations where the transport medium for the messages is temporally scattered.

If on January 1, I send Steen a birthday present, and on Dec 24 send him a Christmas present, it's fine if the birthday present doesn't get there until Dec 26 as long as the Christmas present doesn't arrive until the 27th. Steen, having received one present on the 26th is free to wait as long as he wants for other presents to arrive and then he can open them in whatever order he wants. If he sends me a thank you note for each one, he could send the notes back in the order he received the gifts or the order he opened the gifts. Whichever order he picks, I need to get them in that order. Having said that, it is generally better for all concerned if he sends the thank you notes in the order he received the gifts... if I receive the "thanks for the Christmas present" note first, I may become concerned that the birthday present never arrived and start casting blame on the poor FedEx guy who didn't do anything wrong (well, except for taking almost 12 months to deliver a package, but in this scenario, that's actually ok). Socially, therefore, it is often bad form for Steen to send the thank you notes back in the order he opened them, but it is ok and sometimes desired.

[AristosQueue (NI)]

Daklu wrote:

Labview is way too big for anyone to be an expert in everything. 

Not just big... also a moving target.

[AristosQueue (NI)]

I moved tst's request to rename the terminals to a new thread: https://decibel.ni.com/content/thread/19366

[AristosQueue (NI)]

drjdpowell wrote:

I would say I have two forms of communication (using my "Messenging" framework).  One where the sender is commanding the receiver, where the sender does often depend on the order, and another is where the receiver is requesting notification of published information from the sender.  In the former case, it is usually one actor commanding its own callee, and "enqueuing" commands makes sense.  In the latter case, which often involves requesting the information from multiple senders, it doesn't mean much to say the sender is "enqueuing" messages.   If the receiver requires ordering then it needs to setup the mechanism.  In the paradigm behind my framework, the publisher of information is not responsible for its use; the requestor of the information is.  Actually, this requestor is often a third party (usually the Caller of both sender and receiver) so one often has the situation that neither sender nor receiver is responsible for communication.

Information from multiple senders is not the issue. Multiple informations from the same sender is. You say, "the publisher of information is not responsible for its use; the requestor of the information is". I agree! But the receiver cannot generally make heads or tails of information from a producer when that information arrives out of order. Imagine if you had a tight loop that executed three times and wrote to a network shared variable. Another loop reads from that variable. It is fine if the reader only sees the first and third value. What isn't fine is for it to see the first and third value and *then* to see the second value. If the values should have been monotonically increasing, the receiver suddenly sees a dip and sets off all sorts of alarms.

I have yet to find any scenario where information *from the same sender* going to *the same recipient* has value when it arrives out of order. Saying, "adding a sequence number is a project left for the programmer" just leaves a whole bunch of weight on the programmer that is totally unnecessary since it appears that every message needs it.

Now, this is totally different from putting a sequence number on every message from *every sender*. That kind of global timestamp is not what the AF adds, and that is something that is very rare. And I think this is more the case that you're concerned about.