Unlock actor framework for adding functionality

[HenrikDueholm]

I've made my own copy of the actor framework to implement some changes that I really needed. Because of this I cannot really share code easily and my framework branch is not automatically updated. The changes that I've made could be made without overwriting the framework if only the framework was more open.

(a bit of what you can do with the changes are listed in brackets)

Creating more functionality for actor framework classes should be done through children of the classes in the framework. The way the framework is setup makes it impossible to add functionality to some classes:

- Message Priority Queue

- Message Enqueuer

- Message Dequeuer

- Message Queue

These classes are all obtained with a class constant internally in the framework.

I would really like it if we could have a class input to all these so we can implent additional queue functionality and have this input as part of either an actor dynamic method inside of the Actor.vi that the constants are read from or an input to the launch VIs.

[Magic can be done with enqueue in front combined with batch message children and public scoped read self enqueuer --> self propagating message array]

Changing functionality through dynamic dispatch is the way it's meant to be done. But most of the Actor framework VIs are static dispatch. Vi's that I'd like to make dynamic are:

- Launch Actor Core.vi (and probably all the other launchers as well)

- Actor.vi

- Send Message and Wait For Response

- Send Batch (Or change the class constant to a control

[adding a counter to an actor child would be easy with a dynamic dispatch of Launch Actor Core]

Heavy use of access scopes makes some actions impossible (as intended). I'd like to have the following changed to community scope and added as friends to the Message class:

- Read Self Enqueuer

- Read Caller Enqueuer

[Messages that flush the queue, view the queue status enqueues them self on the queue and so on can be made]

And lastly but surely the most controversial is the change of pre launch init from non-reentrant to reentrant.

Yes by doing this and launching an actor from within the vi will crash your program. But doing it as is will result in a deadlock anyway. The protection of making it non-reentrant is extremly weak! I'd rather have some warnings. What you gain is that the actor that you are launching and the nested actors that it will launch from the pre launch init can share their private data during launch! This is extremely useful with actor shared notifiers, DVRs and so on. Note that you can do this halfway by launching from the actor core.vi however the data will only be shared up in the hierarchy not throughout the entire hierarchy... which is bad/sad.

I hope you'll look into at least some of this to enable a more dynamic usage of the framework for advanced users.

[BillMe]

In my opinion, how deep you can get your hands in the guts of AF should be necessarily restricted. It means I have more confidence that my delivered software will be robust, stable and maintainable which means a happier customer (and in some cases around here involving LabVIEW, that is sorely needed). Besides, wouldn't these changes basically mean N.I. cutting their own throat as far as providing technical support?

Lastly, I don't think your idea has much of a chance anyway just due to the sheer number and impact to the current product. Small, incremental changes are the only way to go in this case.

[AristosQueue (NI)]

Before everything else:  You created your own branch of the AF. That's great! I hope you copied it off to a new directory (so no other applications link to it and get unexpected behavior). I would also encourage you to rename the "Actor Framework.lvlib" to something more personal so that the namespacing prevents cross-links in the future. It will make your upgrade experience more pleasant. And you'll be better equipped to diff any new AF versions against your changes if you want to pull in changes from the main branch.

Now, as for your idea...

> hope you'll look into at least some of this to enable

> a more dynamic usage of the framework for advanced users.

I encourage you to discuss all of these ideas on http://ni.com/actorframework with the advanced users who have helped to build the AF. I'm pretty certain they'll get roundly rejected. I'm going to lay out my own objections here, but it would be useful to have this discussion in the proper forum where it can be evaluated properly. The AF is already used for very advanced and dynamic use cases in its current form.

I believe this idea should be rejected. Everything you request was considered originally in the design of AF. But I also want to respond to BillMe's comment:

> Small, incremental changes are the only way to go in this case.

There will be a new AF (we'll call it something else to avoid confusion) someday that is not backward compatibile. A new conception of actor-oriented programming in LabVIEW. We will continue to support the existing AF, but there are ideas that would take actors in a new direction. So even when discussing radical changes, the door is open for their inclusion. I do not think that applies in this case (for reasons discussed below), but we shouldn't squelch the debate just because it is a non-starter with the AF as it stands at the moment. Five years from now will likely be a very different environment.

1.

Adding dynamic dispatching for the queues injected more performance overhead for the send and receive than was acceptable for many applications. So we cut it out. The biggest performance hotspot in AF is the enqueue operation.

This lack was not a barrier to creating alternate types of communication. Note the Proxy Actors that I built that allow the AF to seamlessly communicate across networks. I did not have to replace or modify the Enqueuer class at all.

2.

> I'd like to have the following changed to community

> scope and added as friends to the Message class:

No need to make those community. Pass that information in as parameters to the Send functions. There's nothing stopping you from creating messages that have that information as required information.

Making those community scoped to the Message class wouldn't help you -- community scoping isn't shared with children. You'd also have to add wrappers to the Message class itself to expose that functionality for children. All of which would be a bad idea... Remember, there are at minimum THREE sources of input to the Enqueuer -- the caller, the self, and the nested. If you've shared the refnum to shortcircuit the tree, there are more. No single sender knows enough to know when it is safe to flush the queue.  Enabling that ability would mean no sender could ever be sure of its communication channel.

Creating "Messages that flush the queue" would be bad, ranging from annoying to disasterous. Even the possible existence of such messages would invalidate most of the guarantees of operation on which the AF depends. Many forum posts on the http://ni.com/actorframework forum have discussed message filtering, and the overwhelming conclusion of the community is that filtration, flushing, etc, should be entirely within the receiving actor and as it processes messages. You can inject a proxy actor into the actor tree to provide filtering, but deciding to dump a block of messages is the receiver's choice alone.

So, in short, the change you ask for would support a use case that does not exist, and if you're doing it for your app, it's because it works in your app, but it would never fly in any libraries of actors that were created for general community use because no one would be able to write reusable actors and have any dependency upon functionality.

3.

> And lastly but surely the most controversial is the change

> of pre launch init from non-reentrant to reentrant.

I am open to discussing any change in the AF, as others will attest, but you have to make your case on thsi one because my current position is, "No. Not just no but hell no." 🙂

The lack of a central initialization safety point is one of the most common breaks for applications that attempt to do massively parallel subsystems. By having this in AF, we have a secure point that protects a huge number of users. If you do not wish to use that safe harbor, then do not use it -- any child actor class is free to establish its own API that users must call on the actor object before calling Launch Actor; you would then use Pre-Launch Init for nothing more than setting an error that says "those pre-launch functions were never called."

> The protection of making it non-reentrant is extremly weak!

Seems pretty robust to me. You're going to have to make this argument.

> Note that you can do this halfway by launching from the

> actor core.vi however the data will only be shared up in

> the hierarchy not throughout the entire hierarchy... which is bad/sad.

It sounds like you're trying to eliminate the entire goal of the AF. Information should NOT be shared up the heirarchy except by messages sent from the nested actors. Each actor is a black box from the point of view of its caller. That's the entire goal.

So, all of that is my opinion. As I say, I'm open to changes, but these don't seem to be advantageous to the AF overall. I will leave the idea open pending more discussion in the AF forums.

[HenrikDueholm]

Really long reply posted on the actorframework forum. Let's move the discussion there as suggested.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.