QMH Message Management

[Gregory]

---

@crossrulz wrote:

I just use User Events instead of queues.  Then each loop registers for the events they care about and everybody will get their own copy of the message.

---

Hi crossrulz,

What does that look like? Instead of loops with "dequeue message", does each loop have its own event structure instead?

[Darren]

---

@Gregory wrote:

What does that look like? Instead of loops with "dequeue message", does each loop have its own event structure instead?

---

In the case of the DQMH I mentioned above, different processes are implemented as "modules". Each module has at least two loops...an event loop and a message handling loop (just like the NI QMH). But the event loop can be registered for user events fired by other modules...that's how the inter-process communication is achieved.

[Ben]

---

@Darren wrote:

---

@Sam_Sharp wrote:

I hope Darren at least agrees that neither answer is 'wrong' ...

---

Hey, there are plenty of people who thing global variables are 'wrong', but I like them. 😉

So yes, abide by general rules when you can, but document your code when the exceptions come up. The general rules are there to keep you from shooting yourself in the foot. If you know what you're doing, sometimes the rules can be bent.

---

The general rule that "globals are Evil" is prompted by an attempt to prevent people from accidently shooting themselves in the foot.

In the very limited specialized cases when developing somthing as simple as a GUI screen thingie you described you CAN get away with globals but those very special cases can quickly change with small change requests from customers.

Example:

The code works great but now I want to be able to change this value on the fly.

Next thing you know the globals need to be replaced with Action Engines (yes real Action Engines not LV2 globlas).

By getting into the habit of using AEs instead of globals, developer will habitually develop more robust code that can be edited by rookies without the train wreck of a global race condition being introduced.

But you are free to have a difference of opipion and keep pushing the idea of globals. I make a living off fixing cod like that.

Ben 

[Gregory]

After looking at the DQMH it seems like you add another parallel process by launching a "module". Whereas in the NI QMH you add another process by adding another parallel loop in the main VI.

The DQMH still uses queues in each module though, so I am curious to see what it would look like to completely remove the messaging queues.

[Darren]

---

@Gregory wrote:

After looking at the DQMH it seems like you add another parallel process by launching a "module". Whereas in the NI QMH you add another process by adding another parallel loop in the main VI.

The DQMH still uses queues in each module though, so I am curious to see what it would look like to completely remove the messaging queues.

---

Within a given DQMH module, having a separate message handling loop (MHL) helps keep the event handling loop (EHL) lightweight. I suppose you could remove the MHL, and move all the message handling code into the EHL, but I wouldn't do it. As the DQMH is designed, the message queue is a local queue for a given module...again, to keep things as familiar as possible with NI QMH users.

Another thing to consider...by separating out the request events and broadcast events like the DQMH does, you can give your module a public API that allows for very easy integration with other code that interacts with the module. You really don't need to know (or care) about how a module is implemented when you're using the public API to send requests to the module, and registering for its broadcast events to receive messages from the module.

[drjdpowell]

---

@Gregory wrote:

The DQMH still uses queues in each module though, so I am curious to see what it would look like to completely remove the messaging queues.

---

You might want to look at the JKI "state machine".  Really it's an event handler that can be a "module" if one adds a User Event to handle externale messages.   It's a single-loop design where events/messages are handled in a case of the case structure.  

[Gregory]

I am familiar with the JKI state machine, that's clever to use it to perform a parallel task. If it is busy doing something when an event is broadcast, will it still hear the event?

[FabiolaDelaCueva]

---

@Gregory wrote:

I am familiar with the JKI state machine, that's clever to use it to perform a parallel task. If it is busy doing something when an event is broadcast, will it still hear the event?

---

You can use JKI State machines and use user events to communicate between them. Justin Goeres gave a great presentation about this on 2011:

http://blog.jki.net/events/niweek-2011-beyond-state-machines-slides-and-code-now-available/

The caveat is that as a developer you have to ensure that you are polling the case with the event structure often so no events go unheard. This is the reason why we decided to have the DQMH be two loops instead of one loop. Another difference between the DQMH approach and Justin's Public/Private events is on the nomenclature. We found that private/public was confusing (specially since public events are wrapped via private VIs and private events are wrapped via public VIs) and decided to go instead for Requests/Broadcasts.

We have talked about this and other decisions in our blogpost: "Ours is not better than yours (YAF)" http://delacor.com/ours-is-not-better-than-yours-yaf/

Regards,

Fab

[drjdpowell]

---

@Gregory wrote:

 If it is busy doing something when an event is broadcast, will it still hear the event?

---

Yes, events are always queued up (the event registration is actually a queue).

[Gregory]

Hi Fab,

I played around a little bit with the DQMH yesterday and was so impressed! The scripting integration was really amazing as well! The only problem I have is that I don't want to get in the habit of using "magical" templates, and I don't understand a lot of the inner workings of the DQMH. I think it offers a lot of functionality and complexity that I have not needed yet, but I know my applications are pretty small. Just wanted to say thanks for putting out such a cool tool, and it's been very helpful to me to learn how to incorporate user events into my smaller projects!