From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
We think that this kind of feature would hide issues from the developers.
Sometimes you can lose communication with clones and can't send any "Stop" request.
In this case, those clones stay in memory in a running state, and it is very hard to kill them. Stop or Kill launcher have no effect. The only way I have found is to close the project but it's not very usefull.
It will be good to have a watchdog mechanism to kill lonely clones
As discussed here JKI SMO and drjdpowell messenger library, have this kind of mechanism.
Hi Eric, the way I solve this issue is by opening the API Tester, then click the refresh button to list the active clones, and send to all a Stop Request.
Hello Enrique and Olivier. You are right, the tester often allows you to re-access lost modules. But in my case, I had several crashes during the development phase and I found myself in the situation of not being able to communicate with these module clones. Even if they stop works well, I find that a self-destruct mechanism would be a plus. I see this as an additional level of security.
With Messenger Library, I find the biggest advantage of the automatic shutdown feature is not needing to write (and debug) shutdown code.
But I'm not sure how well this would work with DQMH, which is more a "group of peers" architecture, than a "call hierarchy" one (like Messenger Library, AF or SMO). Do DQMH modules have a well defined "Caller" who they should not outlive?
Do DQMH modules have a well defined "Caller" who they should not outlive?
No, nothing can prevent a user to start a module and then stop this part of the code. I never dive into Messenger, AF, or SMO, but how they can enforce that?
It's like Queues and most other LabVIEW references. Nothing stops you creating a Queue and then stopping that part of the code, but the Queue is automatically destroyed as well. Queues are not independent of the code that created them, and do not outlive their creator.
With DQMH, you can choose to design a tree-like structure, or go with a flat one. So I think it would be hard to make that kind of „garbage collection“ part of the framework itself 🤷♂️
You could make it on optionally, based on an input to the vi that starts the module. Then users could decide to use it if this module shouldn't outlive its creator.
After giving this some more thought, I have ambivalent feelings to be honest:
Not having to care about where and when to stop "child modules" is definitely handy for experienced software developers, and especially if you're implementing a strict actor tree structure. Without having tried it out myself, I feel like I would still recommend to our less proficient customers to not use the auto-shutdown option but consciously implement the shutdown code where they think it should go.
Also, what Eric seems to be describing ("Sometimes you can lose communication with clones") sounds to me not so much like a request for an additional design tool, but rather a helping hand when things go wrong and clones end up orphaned. For the current implementation of DQMH, not stopping modules is not an accepted scenario - you have to stop your clones, so losing the communication/reference constitutes an error.
Please don't get me wrong: I totally agree that this happens sometime, and that it would be handy to have a way to stop 'em all. I'm just not sure if the option that you describe, James, is the solution to the problem that Eric describes.
We think that this kind of feature would hide issues from the developers.