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

[Daklu]

AristosQueue wrote:

If I go this route... can I call it "Launch Top-Level Actor.vi" and leave "Launch Actor.vi" with the same name? Changing the existing name is a serious mutation that would tie this change to a LV version bump.

Personally I would call it "Launch Independent Actor.vi" to emphasize it is being created outside of the built-in hierarchical chain of control the AF provides.  The adjective "top-level" already has meaning in LV lingo, and while a "top-level" actor shares some similarities to a "top-level" vi, they are dissimilar enough that calling them the same thing will cause confusion.

[AristosQueue (NI)]

Daklu: How are they dissimilar? To me, it was using exactly the same term for exactly the same situation.

[Daklu]

drjdpowell wrote:

Technically an address and a mailbox are different; the first is about message transport while the second is about receit.  As long as the AF isn't going to be extended such that that subtlety matters (it does, for example, in something like RabbitMQ where the terminology is "Channels" and "Queues") then "mailbox" is fine, though I prefer the genericness of "address".  I send messages to an address, even if you receive them via a mailbox.

Actor terminology in Labview is tricky because (in all the LV actor implementations I've seen) sending messages requires us to interact directly with the message transport in code.  However, the Actor Model doesn't include the concept of transports--it just assumes the message will eventually get to its destination.  When I send a letter (or email, etc.) in the real world, the address is affixed to the message.  We don't do that in LV actors, so "address" doesn't work very well and the metaphor breaks down in some scenarios.

The terminology one chooses depends on how one thinks about the various components in the AF, and that depends on both the developer's understanding and the project's requirements.  For example, in some apps it may be perfectly acceptable to ignore the transport cost and think about an actor's enqueuer as an actual inbox for that specific actor.  In other apps the developer needs to be acutely aware of timing issues between actors and it becomes more beneficial to think about the enqueuer as a transport rather than an inbox.

Even though it is somewhat clunky, I think "enqueuer" is a better name than "address" or "mailbox" in the AF.  It accurately describes what it is better than the alternatives.

[drjdpowell]

JackDunaway wrote:

(Akka, a popular actor-oriented framework, likewise uses Mailbox to describe incoming messages to an actor.

Following the link, Akka actually uses "actor references" and "actor paths" for its addresses; the "mailbox" is a receipt method sitting behind one or more addresses.  How's "actor reference" as an intuitive name?

[Daklu]

AristosQueue wrote:

Daklu: How are they dissimilar? To me, it was using exactly the same term for exactly the same situation.

First off, I don't do much dynamic launching of anything, so my understanding of how things work may be way off base.

As I understand it a "top level" vi is one which no other vis own references to it, either as a sub vi or from dynamic launching.  For example, calling Run VI with Auto Dispose Ref set to true launches it as a new top level vi.  Setting Auto Dispose Ref to false launches it with the reference owned by the calling vi.  In other words, a "top level" vi refers to the top of a reference tree that is, for the most part, managed behind the scenes by Labview.  On the other hand, "top level" in a hierarchical messaging actor tree refers to the actor at the top of the messaging/control tree, which may or may not match the reference tree.

Currently the AF launches all actors with the fire-and-forget option, so with respect to references they are all already "top level" actors regardless of where they reside in the control tree.  Giving "ownerless" actors the name "top-level" implies owned actors are not top-level with respect to references, which at some point is going to leave users puzzled when it doesn't behave in ways they expect.

[tst]

My actual problem was less with the term we use for identifying the message target (I think my personal preference at the moment is "queue" or "inbox", although "enqueuer" is also OK) - the problem was with the "caller-to-actor" structure, which makes it a mental stumbling block (it requires you to stop, read it carefully and understand it each time) and I don't think is needed.

[fabric]

drjdpowell wrote:

"Launch Top-level Actor" sounds good to me. 

Agreed. That sounds exactly like what I would be looking for in the palettes when I want to start a new AF project. (PS. I don't think new users would find this confusing compared with the concept of a top-level VI... I do much of my LV work in a top-level apartment and that has never caused confusion with my hierarchies )

And for the side issue: "enqueuer" is pretty horrible... Of all the suggestions I think renaming enqueuer to "queue" would be the cleanest way to improve nomenclature. Most LV users would just "get it" immediately without having to stop and think what an enqueuer really is.

[drjdpowell]

@Daklu wrote:

@drjdpowell wrote:

Technically an address and a mailbox are different; the first is about message transport while the second is about receit.  As long as the AF isn't going to be extended such that that subtlety matters (it does, for example, in something like RabbitMQ where the terminology is "Channels" and "Queues") then "mailbox" is fine, though I prefer the genericness of "address".  I send messages to an address, even if you receive them via a mailbox.

Actor terminology in Labview is tricky because (in all the LV actor implementations I've seen) sending messages requires us to interact directly with the message transport in code.  However, the Actor Model doesn't include the concept of transports--it just assumes the message will eventually get to its destination.  When I send a letter (or email, etc.) in the real world, the address is affixed to the message.  We don't do that in LV actors, so "address" doesn't work very well and the metaphor breaks down in some scenarios.

The terminology one chooses depends on how one thinks about the various components in the AF, and that depends on both the developer's understanding and the project's requirements.  For example, in some apps it may be perfectly acceptable to ignore the transport cost and think about an actor's enqueuer as an actual inbox for that specific actor.  In other apps the developer needs to be acutely aware of timing issues between actors and it becomes more beneficial to think about the enqueuer as a transport rather than an inbox.

Even though it is somewhat clunky, I think "enqueuer" is a better name than "address" or "mailbox" in the AF.  It accurately describes what it is better than the alternatives.

My main point is don't choose terminology that becomes a burden if one extends the system in future.  "Enqueuer", for example, strongly implies to the sender that the receipt of messages will be in order.  If one ever built a "UDP with resend" type distributed actor system then this terminology would become inaccurate.  Don't overspecify the transport in your terminology unless that is a conscious decision to rule-out something. 

And personally, I think of messages being sent to an address.  Not enqueued to a mailbox.  As the sender of a message, I don't care how it gets there.

[AristosQueue (NI)]

OK... I think I'll add a new VI to the palette for 2014... I'll even ask about 2013 SP1, but I doubt I get approval -- that's usually reserved for bugs, even if the change is relatively benign like this would be.

With that decided... I'm willing to follow the tangent that has appeared in this thread. The "naming of things" problem rears its head again.

Everything that follows is on the tangent topic. 😉

drjdpowell wrote:

How's "actor reference" as an intuitive name?

Awful. It makes it sound like it is a reference to the actor, by which I mean a C# or JAVA style object reference. When you're talking objects, "reference" is a very specific term. This is not a reference to the actor. It is a reference to the comm channel by which you talk to the actor. That critical distinction is what makes actors work in multicore situations.

There are too many papers in the world that assume that "Actor oriented" and "Object oriented" cannot exist in the same programming language specifically because they are thought to be antithetical to each other. That assumption hindered a lot of my work in trying to build the AF because I would hit researchers that were totally confused by terminology. The dominant programming languages have claimed the phrase "object reference" and trying to make that word mean anything else is foolish -- especially when LabVIEW has .NET object references and object data value references, whereas this is a totally different type of thing.

I'll stand by "enqueuer". What follows is both a recap of what originally led to the name and some new points that have come up in conversation as the AF has seen wider usage.

drjdpowell wrote:

Don't overspecify the transport in your terminology unless that is a conscious decision to rule-out something.

It was and is a conscious decision for the AF. Having a lossy connection between actors is fine; having messages arrive out of order (from the relative postion of the sender) is not. So a UDP connection would work fine so long as any late arriving messages were simply dropped instead of handled late. That requirement for ordered handling is critical in the validation and verification that the AF was aiming for -- trying to put these mutlicore systems onto stable footing. In sort, it is always a queue. The compiler might in theory decide to make it a mutexless single-entry buffer by synchronizing the send and receive loops of two actors. It might decide to use a lossy queue. Both of those would require a compiler with deeper analysis capacity than we currently have, but it's the 10+ year goal in my vision to get us there.

At some point working toward that goal, we may decide that the existing Actor Framework has to be deprecated and a new framework introduced -- a new framework that isn't backward compatible but lays out the parts of actors in a new fashion, or puts more control over the comm channel into programmer hands. I would still expect "queue" to describe all of those comm channel options.

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. If A happens and then B happens, I observe that we humans assume that the effects of A will happen first and then the effects of B. When those get reversed -- for example, light arriving before a sound, even though the sound was generated first -- we get confused. "Effects ordered in same order as cause" is an insidious assumption that works its way too easily into code... it appeared to me that it was far better for the framework to support that assumption than to leave a programmer open to an unconscious mistake. And having made that decision, we soon realized that being able to depend upon that fact made all of our programmatic code interactions consistent with our UI code interactions -- and UI code interactions are *always* expected to have effects ordered in the same order as cause. If a user types some text and then clicks the OK button, they'd be mightily confused if the text that was committed was an empty string because the effect of the Click registered before the effect of the keystrokes. This rarely happens with UI work because humans interacting with software are so darn slow. But when we automate systems, we run the risk of making things fast enough that this reversal can happen. Events getting dropped do not cause this same confusion -- a sound that is generated but doesn't get heard at a distance makes perfect sense.

In most conversations touting UDP, someone eventually brings up e-mail as a UDP system that works just fine. But tell me -- how confusing would it be if your inbox showed e-mails sent yesterday before e-mails sent today? If it sorted by arrival timestamp, that's what could happen -- even e-mails from the same sender might arrive in reverse order. And that's the cardinal sin -- from the same sender, the conversation no longer makes sense when reversed. For e-mail, there is a deep underlying transport mechanism that is lossy UDP, but at the application layer, everything gets ordered again. From the point of view of an actual observer, ordering always matters for communication.

Priority communication is a special case. Specific messages are known to be brought to the head of the line, allowing their effects to preempt the effects of other messages. This works because the priority level is set by the sender. It is not the result of random effects in the transport layer. As such, communication works because the sender knows that if this message arrives out of order, it will still result in unambiguous communication when received by the reciever. Consider a sender who sends a normal priority message that says, "Undo previous instruction." If that message arrives before the previous instruction, everything is messed up. But a sender who is going to consciously send a priority message sends a message that says, "Ignore or undo the instruction sent at timestamp X" then the sender is preparing for the possibility of unordered receipt.

This need for ordered communication is true in every application I observed. In *theory* an actor *can* be designed such that the order of messages *from the same sender* does not matter. In practice, that never happens in my observation, and I believe my observation has been long enough to relegate the possibility to a statistical anomaly. It thus appears to me to be foolish to try to account for it as a possibility. And so, for these reasons, I believe calling the comm channel a "queue" or "stream" or some other term where order is implied is exactly right.

[AristosQueue (NI)]

Daklu:

You make a good argument against calling this a "top-level actor", even though you made the argument for the wrong reasons. 😉

Daklu wrote:

For example, calling Run VI with Auto Dispose Ref set to true launches it as a new top level vi.  Setting Auto Dispose Ref to ...

The setting of AutoDispose does not matter. Any VI executed through the Run VI method is running top-level -- which means refnums inside of it have the lifetime of the run VI, not the caller. Also, aborting the caller will not abort the VI (except as a side-effect of the last reference being released, which is why such a VI needs to open its own refnum if the caller uses AutoDisposeRef=False). Contrast this with the Call By Reference node -- any refnum opened inside the called VI will have a lifetime tied to the caller and aborting the caller will abort the called VI *even if* the called VI has opened a reference to itself.

I was using "top-level actor" because it was an actor without a caller, just as VIs running top-level are VIs without a caller. But every actor has its own refnum lifetime scope and every actor is immune to abort of other actors. So in those two senses, you're right, they are all "top-level".

How about one of these?

1. Launch Callerless Actor.vi
2. Launch Root Actor.vi

#1 would seem to be a more intuitive name in the palettes for a new user, but #2 drives home the actor tree concept, which might make people hesitate from using it when launching out of an existing actor (which is generally a good idea -- you almost always want that "last ack" to go to someone).

Thoughts?