New Public API VI for all modules: "Start Module and Wait for Initialization"

[Darren]

Many DQMH developers (including myself!) encounter the stumbling block of firing requests before a module is "ready". We assume that the following code is sufficient for starting and synchronizing a module:



The 'Synchronize Module Events' VI ensures that request event references are valid, but it doesn't do anything about ensuring that the module is actually ready. One very common scenario is a module Main VI that includes code in the 'Initialize' frame of the MHL that fires private events to initialize Helper Loops. If the VI that called Start Module isn't waiting on the Module Did Init broadcast, then it could immediately fire a request after calling Synchronize Module Events, and if a helper loop is registered for that event, then helper loop could run the event frame for that fired event before the MHL has had a chance to fire the private event to initialize the helper loop. There are many other possible pitfalls, but this is one of the more common ones I've seen.

To solve this issue, I think DQMH should ship with a Public API VI that is a wrapper for Start Module + Synchronize Module Events, but includes the extra step of waiting for 'Module Did Init'. The module author needs to ensure that the Module Did Init broadcast is called after all necessary initialization code... if they do so, then it is "safe" to begin calling events externally.

Here's my proposed interface for the Start Module and Wait for Initialization VI:

And my proposed implementation:

If this VI shipped with the DQMH singleton and cloneable module templates, it would help us avoid module synchronization + initialization issues like what I describe above.

[Ozfarmboy]

We have this issue all the time and are constantly creating work arounds.  I agree it would be nice to have this as part of the framework, rather than us having to create the workaround each time!

[MichaelAivaliotis]

I think for singletons, you don't want to wait for the event if the module is already running. So a conditional structure might be required if running. Not sure how to handle this with Cloneables.

[Darren]

> I think for singletons, you don't want to wait for the event if the module is already running. 

Right, my proposal includes a mockup of the cloneable 'Start and Wait' VI because it was the more complex implementation. I anticipate the singleton version will look similar to the screenshot you shared.

[FabiolaDelaCueva]

How would we address the issue that registering for the broadcasts after this new VI means some broadcasts would be missed by the calling VI?

Should we instead change the inside of the Synchronize Module Events to have that VI wait for the Module Did Init Event?

[joerg.hampel]

Just as one data point (not saying this feature request should or should not be implemented): This new API would not do much for our modules here at HSE.

1. We never put any business logic into the "Initialize" case (other than starting helper loops etc.). Any module-specific initialization will be implemented in a separate case, possibly triggered via a separate request. Every HSE module has a "Configure" request for that use case.

2. We usually implement our own module-specific "All business code is ready" broadcast where needed, which means that the module is ready to do its job (again, the "Module did init" only reports that the framework has started the module).

[MichaelAivaliotis]

"We usually implement our own module-specific "All business code is ready" broadcast where needed, which means that the module is ready to do its job (again, the "Module did init" only reports that the framework has started the module)."

It depends on what your definition of "Module did init" is. My modules self-initialize, which makes using them a lot easier for me. That way the caller doesn't need to know details about initialization.