You can (and have to) control the timing of the loop manually. DQMH: Enabling the timeout case of the helper loopĪny other value sets your DQMH actor to be wide awake, waiting for that next timeout to occur!Ī timeout value of 0 makes the event structure timeout immediately. Your DQMH actor is effectively put to sleep and disabled. Setting the timeout value to -1 means that the event structure will never timeout. DQMH: Disabling the timeout case of the helper loop Then, you can simply modify the value by the means of DMQH requests. It’s a question of wiring the timeout value of the event structure to a shift register. The beauty of this solution lies in the ease with which the actor can be enabled or disabled. DQMH: Helper loop with an event structure and a timeout case
See the update at the bottom of this post for things to look out for when using the timeout event.
Timings can be controlled by setting the timeout value of the event structure, or by implementing your own timing code within the timeout case of the event structure. The timeout event of an event structure can be used to repetitively execute code. Read on to find out more about these two concepts. We’ve been using helper loops of two different flavours: Either triggering from within – an event structure timeout case helps with that – or triggered through dynamically registered broadcast events from other modules. The event structure registers for the Stop Module event of the DQMH module (see the screenshot on the top of this post). Helper loops are made up of a while loop containing an event structure. This ensures that if the event structure in the helper loop has several events already in the queue, it contains the latest information the next time the timeout is handled. Leave the changes to the local data cluster to be handled via the traditional EHL->MHL and then use a Private Request to update the data in the helper loop. When coding a repetitive operation, use a helper loop that is registered to the stop Module event and does the repetitive operation inside the timeout case. Here’s an excerpt taken from the DQMH best practices website, explaining this very technique: To avoid clogging the message queue and slowing down the MHL, and to gain additional flexibility, we can move the action into a third, separate loop: The Helper Loop.
DQMH: Message handling case calling itselfĭepending on what you want to achieve, this might be the way to go. Take a look at the following screenshot: The Loop Case calls itself, by putting a corresponding message into the message queue, as long as condition = true. The aforementioned, easy way is to have a message case call itself over and over again, as long as a given condition is met. Still, following the easiest and most straight-forward way might not always take us where we wanted to get in the first place. How can we turn a DQMH module into a DQMH Actor? What could that bringing-to-life of a DQMH module actually look like? Any queued message handler already comes with everything we need to bring it to life, you might say.
This blog post is not about the Actor Framework. We want DQMH Actors!ĭQMH Actor: Self-Messaging or Helper Loop?Ĭaveat: When I say actor, I really mean a DQMH module that executes code by itself, without its’ request events being called. Modules shall actively poll for information, acquire data from hardware, manage network connections, and more. We want them to do more than merely sit there, waiting for work to be thrown at them. Sometimes (actually more often than not), we want our modules to be more than passive libraries.