Unload LBLIBP from LV memory

[crossrulz]

---

pawhan11 wrote:

After I replace this PPL will labview notice this is new version of old one and reload it?

---

If the previous PPL is unloaded, then the new PPL will be used when it is loaded.  This may require a restart of your application or close and reopen your project.

[wiebe@CARYA]

---

@crossrulz wrote:

---

pawhan11 wrote:

After I replace this PPL will labview notice this is new version of old one and reload it?

---

If the previous PPL is unloaded, then the new PPL will be used when it is loaded.  This may require a restart of your application or close and reopen your project.

---

But the previous PPL will never be unloaded, because the parent class is never unloaded.

Seems like a big problem. There's no way to make a class based hot swappable plug-in system.

[Sam_Sharp]

Welcome to one of the many serious pitfalls/problems with packed project libraries!

As far as I know (although I can't find any information that confirms/denies it), once a PPL has been loaded into memory, it will never be unloaded and another PPL with the same name cannot be loaded (i.e. to replace it). PPLs allow you to update code without recompiling the source executable, but it still requires an application restart to load the updated plugin.

[wiebe@CARYA]

---

@Sam_Sharp wrote:

As far as I know (although I can't find any information that confirms/denies it), once a PPL has been loaded into memory, it will never be unloaded and another PPL with the same name cannot be loaded (i.e. to replace it). PPLs allow you to update code without recompiling the source executable, but it still requires an application restart to load the updated plugin.

---

That seems to be contradicting the statement that everything is unloaded when possible (which is never for child classes with a parent class in the project).

Have you tried that with a PPL that is not a child class of a parent class that is in the project?

If this is a general PPL problem, there's really no use in searching for a solution for the more specific problem of unloading a child class when the parent is still in memory...

[crossrulz]

---

wiebe@CARYA wrote:

That seems to be contradicting the statement that everything is unloaded when possible (which is never for child classes with a parent class in the project).

---

My understanding is the opposite: if a child class is in memory, then the parent must also be.  Then the question becomes which class type is on any and all of the wires.  If there is a single place where the child is on a wire, then it cannot be unloaded.  I have a few test VIs ready that I could use for testing purposes.  If I can find a little bit of time, I will do some more experiments.

[wiebe@CARYA]

---

@crossrulz wrote:

---

wiebe@CARYA wrote:

That seems to be contradicting the statement that everything is unloaded when possible (which is never for child classes with a parent class in the project).

---

My understanding is the opposite: if a child class is in memory, then the parent must also be.  Then the question becomes which class type is on any and all of the wires.  If there is a single place where the child is on a wire, then it cannot be unloaded.  I have a few test VIs ready that I could use for testing purposes.  If I can find a little bit of time, I will do some more experiments.

---

That does make more sense to me too, but in the idea exchange answer AQ states:

One way [not releasing because there are dependencies] happens is if those items in memory contain classes that are child classes of items in your actual project. We cannot unloade a class once it is loaded unless its ancestor class is also able to unload.

 So that's the parent (or parent's parent, etc).

This would pretty much mean classes in PPL will either be never unloaded, or completely useless. Never unloaded: the parent must be in the exe\project to be useful. Useless: you can't use a dynamically loaded class if it can't be cast to it's parent.

[pawhan11]

Thanks @crossrulz for intrest in the subject 🙂

I have done simple test, only base ppl is placed on the diagram, I call child implementation and later I destroy parent and child. Child remains still in memory. I close vi I used to execute that code. Child still remains in memory. After I close and reopen the project it is gone 🙂 .

[pawhan11]

Another intresting article:

http://www.labviewcraftsmen.com/blog/refueling-in-flight-by-russell-blake

[wiebe@CARYA]

---

@pawhan11 wrote:

Another intresting article:

http://www.labviewcraftsmen.com/blog/refueling-in-flight-by-russell-blake

---

That is interesting. Especially AQ\Stephens remark.

So in an executable, a child class in a PPL won't be unloaded because the parent class is in the executable. This is because any parent class can be a child object. But if all code using the parent stops running (e.g. goes idle), the child is unloaded. So your executable can keep running, but all code using the parent class must go idle.

If you design from start with this knowledge, it's actually doable. Depending on the exact situation of course. It's a pity the hole program has to be designed around this feature though. 

[peper2001]

Hello,

I'm trying to load plug-ins dynamically, based on the very good post mentionned earlier in the discussion:

http://www.labviewcraftsmen.com/blog/refueling-in-flight-by-russell-blake

and on the more recent presentation of Studio bods at NIWeek:

https://www.studiobods.com/en/niweek2018-ts1043/

My main goal is to load (and unload!) different plug-ins that, once loaded, should run in parallel. 

What I observe is that a plug-in gets unloaded only when all other plugins have stopped running. For instance, I load and launch, at the same time, 2 plugins that runs for a different amount of time:

-plugin1 runs for 3s

-plugin2 runs for 10s

I would have expected plugin1 to leave memory after 3s, and plugin2 after 10s but it seems that plugin1 leaves memory after 10s.

==> plugin1 leaves memory only when plugin2 has finished executing (and leaves memory).

Is this expected behavior?

Thanks!