How to insure important messages are handled before quitting

Question

I have a Win32 MFC app that creates a thread which listens on the RS232 port. When new data is received that listener thread allocates memory using new and posts a message to a window using PostMessage. This carries on just fine and the window handles the incoming data and deletes the memory as necessary using delete. I'm noticing some small memory leaks right as my program closes. My suspicion is that one or two final messages are being posted and are still sitting in the message queue at the moment the user shuts the program and the thread closes before that memory gets properly deleted. Is there a way I can insure certain things happen before the program closes? Can I make sure the message queue is empty or at least has processed some of these important messages? I have tried looking at WaitForInputIdle or PeekMessage in destructors and things like that. Any ideas on a good way to solve this?

Answer 1

1. I 100% agree that all allocated memory should be explicitly free'd. (Just as you should fixed all compiler warnings). This eliminates the diagnostic noise, allowing you to quickly spot real issues.

2. Building on Harry Johnston's suggestion, I would push all new data into some kind of a queue and simply post a command "check the queue", removing and freeing data in the message handler. That way you can easily free everything left in the queue before exiting.

Answer 2

For a small utility, that leak might be acceptable - but it might cover other causes that are less benign.

PostMessage does not guarantee delivery. So other options are

• using a blocking SendMessage
• add the data to a deque, use Post Message to notify the receiver new data is available

---

(Remote code review: if PostMessage returns false, do you delete the memory right away?)

Answer 3

The folks arguing to not worry about it have a valid point. The process is about to end, and the OS will release all the memory, so there's not much point in spending time cleaning up first.

However, this does create noise that might obscure ongoing memory leaks that could become real problems before you application exits. It also means your program would be harder to turn into a library that could be incorporated into another app later.

I'm a fan of writing clean shutdown code, and then, in opt builds, adding an early out to skip the unnecessary work. Thus your debug builds will tell you about real leaks, and your users will get a responsive exit.

To do this cleanly:

You'll need a way for the main thread to tell the listener thread to quit (or at least to stop listening). Otherwise you'll always have a small window of opportunity where the main thread is about the quit just as the listener does another allocation. The main thread will need to know that the listener thread has received and complied with this message. Only then, can the main thread go through the queue to free up all the memory associated with the last messages and know that nothing more will arrive.

Don't use TerminateThread, or you'll end up with additional problems! If the listener thread is waiting on a handle the represents the serial port, then you can make it instead wait on two handle: the serial port handle and the handle of an event. The main thread can raise the event when it wants the listener to quit. The listener thread can raise a different event to signal that it has stopped listening.

When the main thread gets the WM_QUIT, it should raise the event to tell the listener to quit, then wait on the event that says the listener thread is done, then use PeekMessage to pull any messages that the listener posted before it stopped and free the memory associated with them.