CListCtrl in Dialog effecting Thread closure.

[vorpalarrow]

I apologize if someone has already asked a similar question.

I have a dialog based application which starts an AfxThread inside my ImageProcessingThread class which continually loops and processes on either a set of images from file or files grabbed from a digital camera. The thread also notifies the dialog which has been set as a listener to use the information that has been retrieved from the processed image.
When the dialog stop button is pressed it sets a variable m_isRunning to false so the main process loop of the thread exits. Before the function that sets the boolean returns it calls WaitForMultipleObjectsEx() on the event handle for m_threadStopEvent which will get set when the main process loop of the thread exits and cleans up it's memmory. Afterwards, AfxEndThread(0) will be called and the thread will have completely exited.

This works fine until I added a CListCtrl to the dialog. Information about the processed image is added to the CListCtrl in the UseInformation() call that gets called after every image is processed in the thread.
With the added CListCtrl being updated inside the thread, when the thread is told to exit it consistently times out on the WaitForMultipleObjectsEx() call.

When I don't update the ClistCtrl, WaitForMultipleObjectsEx() does not timeout. I am really puzzled by this. Processing time does not seem to be an issue because one whole process loop takes less than a second and the timeout is set to 5 seconds.
Why is the CListCtrl interfering with my thread exiting?

When CListCtrl is being updated by the ImageProcessingThread :
If I step through the code, breakpoints in the thread never get reached after WaitForMultipleObjectsEx() is called by the dialog.

When ClistCtrl updating is removed:
The same breakpoints are reached after WaitForMultipleObjectsEx() is called.

[MrViggy]

How are you passing the message to your GUI thread?

Viggy

[MikeAThon]

You might have a deadlock-probable situation, particularly if you are updating the CListCtrl from inside the thread using functions like InsertItem etc. These fucntions are actually thin wrappers over the basic Windows SendMessage(LVM_INSERTITEM,...) functions, which cause inter-thread messaging. However, since your UI thread is blocked in the WaitForMultipleObjects call, it can't process any messages.

See this thread for a similar situation: "CriticalSection DeadLock ?... " at http://www.codeguru.com/forum/showthread.php?t=374980&p=1326103

One solution is to change the way you terminate the thread. Set the m_isRunning variable to FALSE, but don't call WaitForMultipleObjects. Instead, simply return (and set a state variable which indicates to the dialog that it's expecting a message from the thread). Inside the thread, close down the way you want, and then post a message (use PostMessage, not SendMessage) to the dialog's window. The message should be a user-defined message (such as #define THREAD_IS_FINISHED (WM_USER+10) ). Give your dialog a handler for this message, and perform the final thread-termination code there (i.e., whatever code you formerly executed after your WaitForMultipleObjects).

Mike

[vorpalarrow]

Thanks for the help. I'll try using your suggestion.

[kirants]

However, since your UI thread is blocked in the WaitForMultipleObjects call, it can't process any messages.

If WaitForMultipleObjects is the one blocking window message processing, one option could be to use MsgWaitForMultipleObjects