Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Launch Actor.vi has a required input for the caller enqueuer. The code inside even validates that the enqueuer was valid.

I put the existing runtime check in after discussion with the AF community because forgetting to supply the caller meant you were often spawning a totally confused actor. Given that one of the concepts that had lead to the development of the AF was that the caller was a central relationship in most messaging systems worthy of special consideration, we made it required and said you couldn't just wire a Not A Refnum.

I am finding resistance to the Actor Framework uptake surprisingly high because of the top-level VI wrapper, which typically looks like this:

Untitled.png

"That's too complicated," is a common comment.

When I simplify the top-level diagram to just this:

Untitled1.png

I get a much better reaction.

Option 0: Change nothing

Option 1: It would not break backward compatibility for functional hierarchies to remove the runtime check but leave the terminal required. That would make the top-level VI look like this:

Untitled2.png

Option 2: Remove the runtime check and make the terminal recommended instead of required.

Thoughts?

Message 1 of 54
(19,474 Views)

I have heard similar feedback, it seems that jumping through this hoop furthers the "high barrier to entry" thinking I encounter when discussing the AF with people.  I would say that if you do change, option 1 would get my vote.  If people are not in the habit of passing a caller enqueuer to the Launch Actor.vi then the problem will shift from "I dont like AF because I have to employ weird voodoo to launch the top level actor", to "I'm trying to learn the AF but keep getting runaway actors that I cant kill."

0 Kudos
Message 2 of 54
(4,397 Views)

I am in favor of options 1 or 2.

If option 1, I think it's a good idea to include in some obvious place a hint on what to do if you're launching the actor without a caller enqueuer. The concept of a required input that allows an invalid ref is not the most intuitive, but it makes sense on some levels in that it requires the developer to think about what they are doing.

0 Kudos
Message 3 of 54
(4,397 Views)

I don't think launching an actor without a caller enqueuer should affect your ability to kill that actor. You should be able to kill it just fine (using the actor's enqueuer), it just won't be able to send any feedback to its launcher.

0 Kudos
Message 4 of 54
(4,397 Views)

AristosQueue wrote:

"That's too complicated," is a common comment.

Thoughts?

Uhh... at the risk of sounding like an elitist jerk, if that diagram is too complicated then the person probably should spend more time understanding actor-oriented concepts and messaging topologies before using the AF to develop real apps.  I agree with Jon--the lack of understanding will simply redirect the problem to something else, not solve it.

However, I do think option 2 may be useful anyway.  With the run-time check in place it is not possible (AFAIK) to use an AF actor to create an "independent" service within an app, since every actor must have a caller.  (Whether or not an independent actor is a good idea is an open question.)

From an API design standpoint, I think option 1 is ugly.  There's little reason to have that terminal be required if the default object is an acceptable input.  That said, I can see how that option makes sense if maintaining backwards compatibility is more important than a clean API design right now.

0 Kudos
Message 5 of 54
(4,397 Views)

It's not complicated, but it's quite confusing as the very first bit of AF one typically looks at.  Bogs one down in trying to understand what this communication reference is doing.  Also, why have a requirement for every Actor to have a caller if your first operation is to hack up a fake caller?

One other option, BTW, is to have a separate "Lanch Independant Actor" method in addition to the regular "Launch Actor".

Message 6 of 54
(4,397 Views)

Understanding the code and being friendly to new programmers is one question, but even a seasoned AFer can benefit from having to write less code. The first image is basically a hack. Change options 1 and 2 make that hack unnecessary.

0 Kudos
Message 7 of 54
(4,397 Views)

Wrapping the 'ugly' code in a 'top level' actor VI makes the most sense.  No need to change anything exacpt adding this 'helper' VI.  And if the new user wants to understand how the top level works and why the 'hack' is nessesary, they can just open it and read the detail comments I'm sure will be included.

-John
------------------------
Certified LabVIEW Architect
Message 8 of 54
(4,397 Views)

I vote option 2. Functionally speaking, that input is not a requirement so I never understood why the API enforces it let alone the framework the runtime check. I mean I understand why you'd want to enforce convention or typical use cases, but *functionally* an actor that never sends anything back is still perfectly valid.

Yes, launching the top level actor is simple enough, but it is more complex than it has to be, which absolutely is a barrier to teaching.

You want to require a working reference? Fine, I can supply one, but there's no requirement I actually *use* it so why require it at all?

-mje

0 Kudos
Message 9 of 54
(4,397 Views)

The diagram is confusing because it's non-intuitive to use the Message Queue Pair. I know I'm opening a very old can of worms, but the Message Queue Pair makes little sense in the minds of anyone who's been using LabVIEW for awhile and knows Notifiers, Queues, and Events. In addition to being user-unfriendly with its code style restrictions, it requires the user to get used to working with non-primitive data types and special constants like "Not an Enqueuer Refnum" and a queue reference constant (which makes no sense in most applications).

The diagrams that you say people understand are missing the MQP. That's what makes them easier to use.

0 Kudos
Message 10 of 54
(4,397 Views)