DQMH - Ownership of broadcast events

[IFW]

I've just started having a closer look at DQMH and it's inner workings after a workshop and presentation by Delacor yesterday, one thing that jumped out so far is that when launching a module you're ensuring that the ownership of the broadcast events is with the module itself and not the calling application.

In past projects of mine I've always tended towards ensuring ownership is with the caller when I'm spinning off extra threads, the reasoning being that if the caller owns the communication references then if the caller crashes all references will become invalid allowing any spawned threads to also close rather than having the potential for unkillable threads being left behind.

Could you explain your thinking or reasoning behind making the module the owner of the communication references?

[FabiolaDelaCueva]

IFW wrote:

In past projects of mine I've always tended towards ensuring ownership is with the caller when I'm spinning off extra threads, the reasoning being that if the caller owns the communication references then if the caller crashes all references will become invalid allowing any spawned threads to also close rather than having the potential for unkillable threads being left behind.

That is the thing, DQMH modules are simple mortals and can be killed . Because they own their references, even if the caller crashes, another module could still communicate with that module by calling the Start Module again (in the case of a singleton, the Start Module returns the references for the existing module if it is already running and does not attempt to launch it again). The Tester could be executed to stop the DQMH module gracefully.

[CRoebuck]

To add to what Fabiola said. There were three things that led us to make the decision to make the module the owner of its own events:

1. We felt that in many systems, modules were peers. If a module has multiple callers and the launching caller dies, the other callers will no longer be able to communicate to the module.

2. I was keen to be able to use my modules with TestStand. If I launch a module (and create its events) in one TestStand step, as soon as the sequence execution moves to the next step the original VI goes out of memory and the events references are destroyed preventing communication with the module.

3. If a splash screen or launcher is used to create a module's events, as soon as the splash screen (or launcher) closes, communication with the module is not possible.

Creating the events in the module itself (and therefore making it the owner of those events) solves these issues.

Chris

[IFW]

Thanks for the explanations, integration with test stand isn't something I've had much exposure to so it's useful to know that behaviour ahead of time. As for the decision on whether a module should out live it's caller in the event of the caller crashing I guess it depends on the specific application, I've certainly run into cases where modules have been left running in the background of an executable after the main thread crashes with no graceful way of shutting them down, I can however see that in some situations it would be beneficial to ensure that the modules keep running.

I can however see ways in which the DQMH could be leveraged to allow both behaviours to co-exist and be utilised as needed by adding a request that passes in a reference to a module which the module should monitor the status of and act accordingly if the reference becomes invalid (excuse my somewhat garbled explanation)

Ian

[drjdpowell]

IFW wrote:

I can however see ways in which the DQMH could be leveraged to allow both behaviours to co-exist and be utilised as needed by adding a request that passes in a reference to a module which the module should monitor the status of and act accordingly if the reference becomes invalid (excuse my somewhat garbled explanation)

That's the method I use.  Communication is by (receiver-owned) User Event, but a Caller-created Queue is used as a monitor.  If it dies, a shutdown message is sent via the User Event.