Rewriting AF in 2023

[IlluminatedG]

---

@AristosQueue wrote:

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

---

Casey and I tried it after I brought it up in the AF Guild discord. Was pleasantly surprised that it works drop-in as a VIP without breaking existing code. Not going to complain that the sanity check for a parent changing from class to interface behind the scenes wasn't something that was thought of 🙂

Given that it doesn't break existing code could definitely get that integrated upstream.

[yanzhanglin]

The operator's reply message is not very convenient to use. Does anyone have a better suggestion？

[AristosQueue]

> Any scenarios that make auto-stop=false a necessity?

Finishing out communications protocols, safe stating multi-tier hardware. It’s rare but it does happen. There may be other ways of handling it if we change how the Stop message behaves — it’s been proposed that we should be able to differentiate messages from caller from messages from nested actors. After Stop, refuse all further messages from caller but continue processing messages from nested until the actor sends itself a “ok stop for real” message. 

[AristosQueue]

> One (major?) drawback of my suggestion

a second major drawback would be placing shutdown code that should only run after both the helper loops and message loop finish. Putting that into a “cleanup” method would bloat the private data of many actors needlessly.

I can think of a few others that sound bad in my head but might be ok in practice. Overall, I don’t think there’s gain there, but I’m open to discussion. 

[AristosQueue]

> The operator's reply message is not very convenient to use.
> Does anyone have a better suggestion?

Don't use reply messages? 🙂 

Ok, less snarky answer: no, I don’t have a better idea. Even after all this time, the basic model is still right. Interfaces make them So Much Better.

[Dhakkan]

---

@AristosQueue wrote:

Finishing out communications protocols, safe stating multi-tier hardware.

---

Yes, I understand these 'long-running' shutdown steps can be necessary. However, I don't understand why it is necessary for the caller actor to not wait for such sub-actors to complete their shutdowns.

Would this be the only way multiple such shutdowns could be run concurrently, thereby reducing the system stop time by design?

---

@AristosQueue wrote:

There may be other ways of handling it if we change how the Stop message behaves — it’s been proposed that we should be able to differentiate messages from caller from messages from nested actors. After Stop, refuse all further messages from caller but continue processing messages from nested until the actor sends itself a “ok stop for real” message. 

---

That would be interesting! Perhaps, when the actor enters this 'Stopping' state, it could issue a 'AmStopping' message to its caller too, enabling the caller to not send any further messages down past this point.

[justACS]

---

@Dhakkan wrote:

---

@AristosQueue wrote:

Finishing out communications protocols, safe stating multi-tier hardware.

---

Yes, I understand these 'long-running' shutdown steps can be necessary. However, I don't understand why it is necessary for the caller actor to not wait for such sub-actors to complete their shutdowns.

It's more that it's not necessary to make the caller wait for its nested actors in a lot of cases.  Safe shutdown procedures increase the complexity of the base actor, and it's likely that there are competing approaches to those procedures.  These are both reasons to leave safe state implementation to end users.

Why one might wish not to auto-stop an actor is a separate question, given that safe shutdown is not standard behavior.

It's probably worth mentioning that auto-stop was added in 2013 or 2014, and there may be some long running AF applications out there that rely on the old behavior.  Though I suspect those systems are mostly in our rear view mirror at this point.

---

@AristosQueue wrote:

There may be other ways of handling it if we change how the Stop message behaves — it’s been proposed that we should be able to differentiate messages from caller from messages from nested actors. After Stop, refuse all further messages from caller but continue processing messages from nested until the actor sends itself a “ok stop for real” message. 

---

That would be interesting! Perhaps, when the actor enters this 'Stopping' state, it could issue a 'AmStopping' message to its caller too, enabling the caller to not send any further messages down past this point.

---

If implemented at the base level, it would add behavioral state to every actor in a system, which I'm not convinced is necessary or desirable.  If actors are the primitives of the model, then at least a few actors in the system are apt to be quite simple.  I wouldn't want to bloat those unnecessarily.

[CaseyM]

---

@AristosQueue wrote:

> 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? 🙂

---

I'm not understanding why you'd need additional parameters in order to make this useful. If you need more information in <Launch Nested Actor> then add that information to the private data before you call that VI. What am I missing?

Anyway, one use case where this would be helpful that comes to mind relates to error/event/status logging. Sometimes with logging, that's the rare instance where I'll intentionally ignore the actor tree. (Side note, I'll often use an additional base class ancestor for all actors for a given application.) The first thing I'll do after the root actor starts is launch a logging actor and then I'll store the logging actor's enqueuer. Then whenever any actor in the system launches another actor I copy the logging actor's enqueuer into the private data of the nested actor. (The idea is that for certain types of logging, I want to avoid any potential bottleneck with Msgs in the actor tree entirely.)

In this case, I'll end up creating an additional subVI that copies the logging actor enqueuer to the nested actor and then calls <Launch Nested Actor> and then I end up using that whenever I would have originally used <Launch Nested Actor>. Whenever this happens, I invariably end up thinking "this would have been simpler and less confusing for other developers if <Launch Nested Actor> was dynamic dispatch".

[CaseyM]

---

@justACS wrote:

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.

Definitely making AF more PPL-friendly would be nice. Without some manual tweaks to the build process, you also lose access to things like "Time-Delay Send Message".

[paul.r.r]

---

@CaseyM wrote:

---

@AristosQueue wrote:

> 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? 🙂

---

I'm not understanding why you'd need additional parameters in order to make this useful. If you need more information in <Launch Nested Actor> then add that information to the private data before you call that VI. What am I missing?

Anyway, one use case where this would be helpful that comes to mind relates to error/event/status logging. Sometimes with logging, that's the rare instance where I'll intentionally ignore the actor tree. (Side note, I'll often use an additional base class ancestor for all actors for a given application.) The first thing I'll do after the root actor starts is launch a logging actor and then I'll store the logging actor's enqueuer. Then whenever any actor in the system launches another actor I copy the logging actor's enqueuer into the private data of the nested actor. (The idea is that for certain types of logging, I want to avoid any potential bottleneck with Msgs in the actor tree entirely.)

In this case, I'll end up creating an additional subVI that copies the logging actor enqueuer to the nested actor and then calls <Launch Nested Actor> and then I end up using that whenever I would have originally used <Launch Nested Actor>. Whenever this happens, I invariably end up thinking "this would have been simpler and less confusing for other developers if <Launch Nested Actor> was dynamic dispatch".

---

This would be my use case as well, transferring application resources that both actors consume, such as an event logger reference.

I think AF debug should be an injectable, OOP based design - LabVIEW ships with a default implementation that calls the current design, but you can inject your own if desired.

I've also wondered why handle last ack has the message as it's input, rather than unpacking the message data in the do like other messages.