How to deal with time consuming MHL cases properly

[Jens_S]

Hello!

I'm currently running into the problem that I have a MHL case (initialization of test hardware) that is taking a lot of time and thereby blocking my MHL. This case includes a lot of waiting for hardware to boot up or to restart so there is no way for me to speed up the process.

To not block my MHL and to follow the best practices for DQHM I put the entire init phase (9 single steps) into a helper loop with a state machine. The obvious advantage of this is that I not longer block my MHL case and can skip single steps in the state machine for debugging very easy. The big downside is that I now need to deal with requests/ MHL cases that can occur while the init phase is not finished. I'm not sure if using the helper loop is the best way to go or if it would be a better/ simpler solution to put the state machine back into the MHL case so I don't have to deal with other request while the system ist not initialized properly (this init case is guarantied to be the first in the queue).

Checking the proper init before processing another request seems like a lot of "overhead" especially if I have a lot of public requests. I would really like to know how you deal with this kind of situation cause there will be a few more requests later on that will take quite a while to finish and can not be interrupted or stopped while executing.

Best regards

Jens

[drjdpowell]

How long are you talking about?  And what do you want the User to be able to do while the program hasn't initialized?  What is wrong with just a "hardware initializing; please wait" dialog?

[Jens_S]

Right now we talk about 2-3 minutes and in the future it might take even longer (when additional hardware is connected to the system). While the system is initializing the user can't do anything other than trying to close the program so there is not a lot that can go wrong.

Sometimes you only need someone who is asking the right question to realize that there isn't really a problem at all. So thanks 🙂

[Jorge_Amaral]

Hello Jens_s,

I tried to create a DQMH template to my projects to be used to communicate with devices. And I can share it with you. It's nothing fancy.

My idea was:

• to be an active module;
• handle the requests on the MHL properly.

With that in mind I have an helper loop that handles the communication with the device. And if the user send a request to this module, if it's not in the "idle" state the event should be discard.

Check it! And if that helps you.

Best regards,

Jorge Amaral

[drjdpowell]

---

@Jens_S wrote:

Right now we talk about 2-3 minutes and in the future it might take even longer (when additional hardware is connected to the system). While the system is initializing the user can't do anything other than trying to close the program so there is not a lot that can go wrong.

Sometimes you only need someone who is asking the right question to realize that there isn't really a problem at all. So thanks 🙂

---

I actually disagree with the idea that it is best practice to make "non-blocking" and "responsiveness" the primary design principle, with duct tape added to fix any race conditions, such as when the User annoyingly clicks a button somewhere in your 9-part initialization.  Instead, I favour "no race conditions", "determinism" and the simplicity of not caring when the User pushed that button.  Only if this leads to an unacceptable responsiveness do I introduce targeted complexity to deal with that.

[drjdpowell]

---

@Jorge_Amaral wrote:

And if the user send a request to this module, if it's not in the "idle" state the event should be discard.

---

I didn't look at your template, but I hope you have a mechanism to throw an error if a request is discarded.  Race conditions that lead to silent dropping of requests are even harder to debug than ones that produce clear errors.  

[Jorge_Amaral]

Hello,

In my usage it's not really important. But it's only a matter of sending a broadcast with that information.

Have a nice weekend!

[Taggart]

---

@drjdpowell wrote:

---

@Jorge_Amaral wrote:

And if the user send a request to this module, if it's not in the "idle" state the event should be discard.

---

I didn't look at your template, but I hope you have a mechanism to throw an error if a request is discarded.  Race conditions that lead to silent dropping of requests are even harder to debug than ones that produce clear errors.  

---

Interesting because that is definitely not what I remember from the AF class. I remember silently discarding messages as being a promoted way of dealing with "out of order" messages.

Generally, I've used that strategy for things like "Hey Start the motor" when the motor is already running, which hasn't seemed to cause me any problems.

Then again I feel like you have a lot of experience and wisdom, so if you say it is an issue, then maybe I have just always gotten lucky and should reevaluate that strategy.

[drjdpowell]

That's because your true message was "Start the motor (if it isn't running)" or "make sure motor is running", and you did successfully execute that request.  

The problem is if you don't make sure the motor is running because you are in a temporary state where you can't start the motor.  Code that expects the motor to be running needs to know that, via some kind of error mechanism.

[Jorge_Amaral]

Hello,

Let me clarify that I only shared my template to help Jen_s. It was never my purpose to be an example that follows the best rules given on your AF class and to be full of wisdom. It was my first attempt to create a DQMH module to be developed during the next times in my projects.

Feel free to share your version to all because I always want to learn with the best praticses.

Br,

Jorge Amaral