Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Auto Self destructing actors

Solved!
Go to solution

@manig wrote:

 

4. To optimize the number of the loop running in parallel,


"Loops" have little overhead; it is your Camera acquisition and streaming that you need to avoid when unnecessary.  Why have you titled your post "Auto Self destructing actors" rather than "Camera Actors that only collect images when someone actually wants them"?

0 Kudos
Message 11 of 15
(1,359 Views)

Powell, I felt it would be a common use case and that is the reason I named it that way. Though it might be overkill for this application which I suspected when posting this question I wanted to know how to do it. Let me know if you feel this will not be effective in any kind of application and would recommend against it. For now, I will accept the Taggart and Christian solution.

 

Thanks,

Mani.

0 Kudos
Message 12 of 15
(1,340 Views)

I think what Dr. Powell is trying to say is it seems you are making your code more complicated for no real benefit.

 

It's not the end of the world, but it will make your code harder to understand and maintain in the future.

 

To be honest I agree with him. I took the challenge on at the very beginning and came up with a demo simply because I was intrigued and it had been a while since I had used the actor framework, so it was en excuse to keep those skills fresh.

 

Thinking about it, while it is certainly possible (the demo proves that ), I don't think I see a use case where I would use it and I don't recommend it.

 

It's your code, you can do whatever you want and that will certainly work.

 

Good luck on your project.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
0 Kudos
Message 13 of 15
(1,332 Views)

The standard model for lifetime of a component is that it is created and destroyed by a higher-level component, rather than "self destructing".  One certainly can do the later, based on some signal, but the common such signals that can simplify programming are just "self destruct if you lose communication with the component that would otherwise tell you what to do" or "self destruct if you are unable to carry out your prime function any more due to error".  Self destructing due to some message timeout, because you think this probably means you aren't needed by higher-level components, seems to be potentially problematic, with higher complexity and bugs where you shutdown when you shouldn't have.  Also note that any Actor that might destroy itself at any time may also might not handle that last important message you just sent it (as it had been in the process of shutting down), thus suddenly a lot of your code needs extra retry logic to avoid race condition failures.  Why not just have a "Camera Manager" component, in full control of lifetime, that knows when to Launch and Shutdown Camera Actors based on need, rather than have the Camera Actors try and deduce when they should shut down based on their limited information?

Message 14 of 15
(1,314 Views)

@drjdpowell wrote:

Also note that any Actor that might destroy itself at any time may also might not handle that last important message you just sent it (as it had been in the process of shutting down), thus suddenly a lot of your code needs extra retry logic to avoid race condition failures. 


Totally missed that one.  That just further convinces that this would not be a great idea.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
0 Kudos
Message 15 of 15
(1,304 Views)