Stop module.vi for cloneable running as singleton - wait for module to stop

[psmorris]

Hiya, 

What's the basis for always waiting for a module to stop in the stop module vi when running a cloneable module as a singleton? It's documented in the vi description that that is the expected behaviour, but I was wondering why. Also, is it ever safe to wire an "AND" to the boolean selector into the case structure "DQMH_POLL_RUNNING_AS_SINGLETON" so that it only sees true IF running as a singleton AND wait for module to stop =True?

I had previously (and perhaps foolishly seeing as how I now see its in the vi description) added that AND functionality to prevent the VI waiting for stop when calling the stop module.vi from within a module which is running as a singleton despite being cloneable... that was because I was seeing that vi essentially timing out in that case and therefore taking longer than expected to stop... (I dont actually do that any more as I found a much cleaner way of exiting from within the module).

So now, I was just wondering what the reasons for that decision were and if it can be omitted safely as I did, or whether i need to go and chase down the modules I did that in and change the behaviour back and refactor to get what I need.

For info, I almost always make my modules cloneable but in some cases will change the "run as singleton" input to the start module a true constant to force them to run as singletons as for now I only want that behaviour, but am concerned that in the future I might want to make it cloneable after all...

Thanks!

Paul

[Darren]

The internal module state for a cloneable running as singleton is different than the state when running as cloneable. If you try to start a cloneable (running as cloneable) while a cloneable running as singleton is shutting down, things "won't work". So we force a complete shutdown of a cloneable running as singleton before letting you fire things up again.

[psmorris]

Ok, so bad idea to add the and logic. Got it.

You mention specifically the case of having a cloneable being launched as a cloneable whilst an instance of that same cloneable running as a Singleton is shut down as an issue, what about the case where it's always being called as a Singleton? (I.e. I've hard coded a true constant inside the start module vi). Could that cause issues? 

Generally I think the modules I have created as clone able but running as Singleton are fairly long lived and not stopped started, but worth a check now for sure. 

Thanks for the quick reply.