How to manage singleton content for cloneable modules?

[1984]

I have a singleton DQMH module which is capable to serve several test stations. Its all working fine, but I'm considering to run the convert singleton module to cloneable function recreate it as cloneable. One caveat though is that for the modules to work certain initialization is required and the modules should share some common references and also when the last module is destroyed I need to close those references. I can solve this several ways, for example I can move the initialization part out of the modules and pass the refs to the modules when they are created. Or I can create a dqmh module for the init and destory.

I'm wondering what is the best practice? Is it possible to keep the init and the destory part in the cloneable modules, but force them to execute that part of the code only once? How should I manage sharing the resources than? With a non-reentrant FGV?

Thx.

[joerg.hampel]

Perhaps it makes sense to have a singleton that maintains said references and the cloneables are "wrappers" for that singleton? That sounds like a clean solution to me. 

[1984]

---

@joerg.hampel wrote:

Perhaps it makes sense to have a singleton that maintains said references and the cloneables are "wrappers" for that singleton? That sounds like a clean solution to me. 

---

This could work as well, but I ended up stripping the cloneable functions from the original module, and recreated them in a cloneable one. The original can output the necessary references and the instances can take them. In the future I may try to add wrap the singleton into the cloneable one which could be cleaner.

If I do so, would it make sense to launch the singleton in the init case of the cloneable and take the references from there? And then stopping the singleton when the last cloneable instance stops.