Ability to Get Actor Enqueuer by Path

[PrimaryKey]

Please add to AF:

Ability to Get Actor Enqueuer by Path through hierarchy of actors e.g. /root/pactor/chactor could be used to get the enqueuer to chactor. This would probably require actors to have unique paths pointing to them. Having a system manager keeping all enqueuers on local system is not a bad thing. It is a good thing.

[drjdpowell]

I would advise against this idea, because it is a global means of connecting anything to anything.  If you do do this, include a way for a calling actor to disable it for its own subsectors.  Otherwise there is no way to keep a subactor private.

[PrimaryKey]

I absolutely agree that simply making everything addressable is not the way to go, but having this as an option, which is disabled by default e.g. Launch Actor method has a Boolean flag to Register in System Manager?

This would make sub-actors without public API still private, but the public actors could more easily talk to each-other, maybe also over the network?

[AristosQueue (NI)]

TL;DR: The AF was written as an allergic response to publish-subscribe systems that had failed many users. It makes other tradeoffs to avoid the downsides of publish-subscribe. It deliberately eschews any support for publish-subscribe, but you're free to add your own if you think it is a good idea. I will try to talk you out of doing so (and I've successfully talked many developers out of it).

Details:

This idea contradicts the goals of the Actor Framework. You can write code to shortcircuit the actor tree for performance reasons, but we do not build into the system a way to make that easy or typical. The absence of any sort of "look up the queue" is very deliberate and has been debated on many ocassions.

The AF treats arbitrary publish-subscribe as a bug, not a feature, based on the sheer amounts of code that lead to echo chamber, race condition, and deadlock bugs with that type of code. The inability to get an arbitrary actor's enqueuer is critical to the whole design philosophy of the Actor Framework. An actor should not know about the existence of any actor other than its direct caller and its immediate nested actors. How could it possibly even construct a path to things that it doesn't know about? The lack of extended vision allows for the exact message playback and the elimination of multiple classes of race conditions.

There is no difference between publish-subscribe and the use of global variables, and they have the same downsides. Publish-subscribe has an additional downside that you cannot even tell who is using the module (usually touted as an advantage by code writers, and a disadvantage by code debuggers and maintainers). Publish-subscribe runs into problems with error handling and lifetime management that the AF handles gracefully. 

Routing messages through a hierarchy requires reinterpretation of those messages at each level of the hierarchy. This is annoying and frustrating. I acknowledge that. But it is an annoyance that pays dividends in the long term by keeping each actor focused on its own single responsibility and minimizes the dependence between actors.

It would be nice to have better tools for generating entire sets of messages to route through a hierarchy, but adding tools to simply bypass the hierarchy is not the answer.

This idea will be declined.

[Darren]

Declined for reasons listed here: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Ability-to-Get-Actor-Enqueuer-by-Path/idc-p/3989884/h...