JDP Science Tools

cancel
Showing results for 
Search instead for 
Did you mean: 

Rediscovering a lost Actor ref

Solved!
Go to solution
Highlighted

James,

 

I have an established architecture in place which launches many actors, sequentially, for various purposes, with each docking its FP into a subpanel on my Main. The life-time of these actors is fairly short (minutes) and I am regularly launching, showing, de-docking and shutting them down. When they shutdown I throw away their messenger ref.

 

Now I have a new requirement to keep all these actors running at all times, and instead of shutting them down I simply wish to alter which is shown in the subpanel. Unfortunately because I have not kept the messenger ref I do not have a means to communicate with these actors after I de-dock them.


Is there a method for recovering the actor class reference for an Actor2 type actor that is still running? It would be great if I could simply re-establish the communications with any running actors, this would save me from re-developing the architecture somewhat.

 

Thanks in advance!

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 1 of 7
(146 Views)
Highlighted
Solution
Accepted by topic author Thoric

The simple answer is "no", and deliberately.  There is a sound reason why references such as DVRs, Queues, etc. don't have any way to identify which ones exist, even though that would be very easy functionality to add.  It's because doing so basically makes all such reference global in scope, which leads to potentially unreadable complex code.  Imagine having some Queue shared between two loops, and some unrelated bit of code "recovers" that Queue and does stuff with it; a debugging nightmare.  There is a big readability advantage to be able to instantly see that a reference is used here, and there, but nowhere else.

 

Thus, like other references, you need to keep track of actor addresses.  How about an array, or one of those new Maps?  You could put it in a Functional Global if you want Global accessibility.  How do you expect to be able to put them in the subpanel if you aren't going to keep track of an array of something?

Message 2 of 7
(140 Views)
Highlighted

Certainly, I understand the CS reasoning why we shouldn't be able to recover the references, I agree completely that it's a debug nightmare. Bearing in mind that, if a queue/notifier/semaphore 'name' is known you can create a reference to it at any time, so throwing it away at one stage and reacquiring it later is perfectly achievable in LabVIEW.  I was just hoping for something in your framework, such a queryable registration service that allowed me to do that same using a new class instance of the same non reentrant actor.

 

I'm happy to modify the architecture, it won't take long, I was hoping to cheat here, I was looking for a quick win.

 

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 3 of 7
(131 Views)
Highlighted

@Thoric wrote:

Bearing in mind that, if a queue/notifier/semaphore 'name' is known you can create a reference to it at any time, so throwing it away at one stage and reacquiring it later is perfectly achievable in LabVIEW. 

 


If you look at the "Actor Manager" it uses Named Notifiers to get info about all running actors.  But this is a breaking of local scoping specifically for a debug tool.  It's a quick hack, not a quick "fix".

 

Also, IMO, using named Queues/Notifiers is never simple**.  They have uses for Global Scoped things, but Global Scope is always tricky.  You'll note they never made Named DVRs.  

 

**Named Semaphores are hopelessly broken (potential for lockup) and should never be used.

0 Kudos
Message 4 of 7
(116 Views)
Highlighted

Actually, if I ever have serious time to improve the Actor Manager Debug tools, I would want to make a diagram of all actors showing who is registered to which notifications from who.  This would involve multiple violations of scoping only OK in a debug tool that does not affect the application itself.

0 Kudos
Message 5 of 7
(114 Views)
Highlighted

@drjdpowell wrote:

@Thoric wrote:

Bearing in mind that, if a queue/notifier/semaphore 'name' is known you can create a reference to it at any time, so throwing it away at one stage and reacquiring it later is perfectly achievable in LabVIEW. 

 

Also, IMO, using named Queues/Notifiers is never simple**.  They have uses for Global Scoped things, but Global Scope is always tricky. 


Note I never used named queues, nor am I condoning it. I was only hoping for a quick win in this situation.

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 6 of 7
(93 Views)
Highlighted

I can't publish code, but I can say roughly how I put together a solution for myself.

 

I made a registrar actor that other actors could voluntarily register with. The registrar keeps a list of actors, the register, which is a singleton object. Then I made a class of snitches that were the only other objects that could read the register. You want an actor's messenger? You have to instantiate a snitch and funnel all your requests through it. You ask for actors by names or by tags that describe their role in the ecosystem. Internally, the register is implemented as a dictionary (like the new maps, only LV2018 style, i.e., stored in variant attributes). There are some things that qualify as a bad code-smell, like DVRs in global Qs / notifiers, but they are hidden by GOOP classes which abstract them into class variables. GOOP also provides by-reference object semantics in a sane way in LV. 

 

I wholeheartedly endorse all the caveats about building a non-hierarchical swamp of actors. If you aren't disciplined (heck even if you are) you can make an environment that is undebuggable and unsupportable. Caveat programmer.

0 Kudos
Message 7 of 7
(82 Views)