Rewriting AF in 2023

[CaseyM]

Knowing what you know now, if you had to rewrite AF today, what changes would you want to see (if any) from its current implementation?

Here's a quick example. I'd make "Launch Nested Actor" dynamic dispatch. 

[AristosQueue]

> I'd make "Launch Nested Actor" dynamic dispatch. 

That was explicitly rejected during design, so I’d need details about your use case before agreeing. Every proposed override for it required additional parameters. For example, my extension for “Launch Remote Nested Actor.vi” needed IP address. The nested op was so foundational to correctness of the AF tree that allowing overrides, even with Must Call Parent enabled, seemed foolish without a clear compelling use case. So… what’s the case? 🙂

[IlluminatedG]

You already know mine 🙂 https://www.vipm.io/package/illuminatedg_lib_af_message_as_interface/

[justACS]

I have two things on my list

1)  Restructure the two libraries to make them PPL-friendly.  Right now, if you build an AF PPL, you lose access to the interface to the debug tools.

2)  Add a protected method to Actor.lvclass to stop its nested actors (the ones set to auto-stop).  It would be a single VI with no inputs.  The use case is to facilitate controlled shutdown scenarios, where the caller needs to request a stop and then wait to hear back before stopping itself.

[StevenHowell]

Make the Launch Root Actor where you can expose the dequeuer and use it to read messages from the root (read messages on the root queue).

Launching an Actor in the original way where you can get to the dequeuer to be able to get messages from the root on shutdown, etc. 

Make that one VI to where you could choose the implementation on the fly. 

[AristosQueue]

I think I’d make Message be an interface. Not absolutely certain (haven’t peer reviewed that theory), but I think so. 

[AristosQueue]

Just saw IlluminatedG’s post. Apparently someone else likes the message interface theory. 🙂

[AristosQueue]

1. Replace Enqueuer with channel wire. 

2. My Actor-as-first-class-LabVIEW-citizen, with a custom diagram type and directly definable/visualizable actor tree. But that requires C++ changes, and I don’t see that happening ever. 

[justACS]

---

@AristosQueue wrote:

1. Replace Enqueuer with channel wire. 

---

Do you have a way to dynamically instantiate a channel wire connection?  Otherwise, that's a deal breaker for me, as I do too much with ephemeral actors.

[Dhakkan]

---

@justACS wrote:

2)  Add a protected method to Actor.lvclass to stop its nested actors (the ones set to auto-stop).  It would be a single VI with no inputs.  The use case is to facilitate controlled shutdown scenarios, where the caller needs to request a stop and then wait to hear back before stopping itself.

---

I have never understood the benefit of setting a nested actor to NOT auto-stop. To me, it's like detaching an actor and making it root. Any scenarios that make auto-stop=false a necessity?

I prefer to have the default of cascading shutdown, where an actor sub-tree shuts down starting with the leaf nodes and propagating up this sub-tree until reaching the actor that was (self-)requested to stop. Non-default behavior can be deliberately coded through custom messaging.

Could Actor Core be made into a static template so that it can never be overridden? Instead provide dynamic-dispatch VIs for 'Setup Core' and 'Core Helper' like this:

One (major?) drawback of my suggestion is UI Actors. Their control/indicator references can never be part of the actor core directly, unless one uses VI scripting to build a map of such references in Core Setup. A static VI reference to the Core Helper (UI Front Panel) would have to be provided for building such a map.