Click here to Skip to main content
15,851,453 members
Please Sign up or sign in to vote.
4.33/5 (3 votes)
I'm having a problem with my dongle heartbeat. We have been using a timer to send a heartbeat to our dongle to keep the license alive. However, if one of our processor-intensive subprocesses takes longer than the dongle license timeout, the application needs to be restarted.

The subprocess in question involves running a third party console app and redirecting its output to our log file. This sub-app is launched using ::CreateProcess. Since WM_TIMER is a low priority, the heartbeat timer messages get shunted off and the license expires.

So I thought what was necessary was to put the heart-beat timer into its own thread. I did this, but the ::CreateProcess appears to block all threads in the parent app.

I don't want to run the sub-process asynchronously, so how do I get my heart-beat thread to keep running at the same time?

Additional:
My timer thread is essentially this:
Threads And Timers[^]

And I just noticed that my console redirection class (optionally) does a WaitForSingleObject on the created process, which is presumably what blocks the parent threads. Essentially, I need my parent app to continue with its 'background' threads while waiting for the spawned process to finish (without using WaitForSingleObject?).
Posted
Updated 17-Jun-17 0:34am
v2
Comments
Jochen Arndt 26-Jul-12 3:03am    
CreateProcess returns immediately and would not block. So the problem must be somewhere else.

Did you still use WM_TIMER in your new heart-beat thread? If so, use WaitForSingleObject with the heart-beat time out value and a kill event handle set upon program exit. Then the heart-beat timer does not need message handling. You may also set the priority of the heart-beat thread above the priority of your main application.
pasztorpisti 26-Jul-12 4:35am    
The problem can also be in the process being launched. I observed that some porocesses work so intensively (especially some antivirus software in nightly mode) that you feel it on the user interface even on an intel i7.
Code-o-mat 26-Jul-12 4:54am    
Can you show us what that thread does? You could use the "improve question" link under your post to add some relevant code sniplets, don't forget to tag them accordingly.
Jochen Arndt 26-Jul-12 6:54am    
To your update:
The timer thread you are using is not the best choice because it is still using the Windows Timers.
My suggestion:
- Create a worker thread and a terminate event
- In the worker thread use WaitForSingleObject with the terminate event handle and your heart beat timeout inside a while loop.
- Upon terminate event, leave the loop and return from the thread.
- Upon time out, execute your heart beat function.
- Upon program exit, fire the terminate event.

Optional set the thread priority one above the main app priority (see AfxBeginThread). Your external process will probably have the same priority as your main app. Then the heart beat should work (if not delayed by heavy system load with higher priorities).
enhzflep 26-Jul-12 10:39am    
If this was an answer it could be up-voted...

1 solution

From the updated question and the comments, this seems to solve the problem:

Using the Windows timers is often not the best choice. For periodic actions that are hardware related and/or sensitive to system load, a worker thread may be a better solution:


  • Create a worker thread and a terminate event.
  • In the worker thread use WaitForSingleObject() with the terminate event handle and your heart beat timeout inside a while loop.
  • Upon the terminate event, leave the loop and return from the thread.
  • Upon time out, execute your heart beat function.
  • Upon program exit, fire the terminate event.

Optional set the thread priority one above the main app priority (see AfxBeginThread). Your external process will probably have the same priority as your main app. Then the heart beat should work (if not delayed by heavy system load with higher priorities).
 
Share this answer
 
Comments
SoMad 28-Jul-12 3:58am    
I agree with this approach, +5.
I rarely have good results when I try to apply priorities to threads as it just seems to create other issues. In this case, it could be a valid option since this thread is not really doing a whole lot.

The OP said he would mark this as the answer - I hope he did not forget.

Soren Madsen
Jochen Arndt 28-Jul-12 5:07am    
Thank you.
You are right that increasing the priority is an option for this problem, but may be counterproductive with other scenarios. It's only an option when the threads execution time is short and the intervals are not too short.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900