I made a debug window in the app I am working on, a part of a COM component. Then I noticed that any message-generating activities on this window (using the scroll bar or just dragging the window)locks my app. This is a multithreaded app that heavily uses synchronization tools (mutexes, events, messages).
I found numerous references (in Microsoft documentation) of potential problems in using WaitForMultipleObjects function with COM, instead of MsgWaitForMultipleObjects. They say that since all input messages (say from dragging the debug window) are broadcasted over all windows of a thread (if CoInitialize is called - an apartment is created in the client thread) using WaitForMultipleObjects may create deadlocks (all these parasite messages are not removed from the queue of the COM-generated hidden window). So I rewrote this app hoping that using MsgWaitForMultipleObjects would fix the problem. Not at all! same deadlock.
Another possibility is that the CSingleLock class I use for locking common resources, uses WaitForSingleObject (in .Lock()) - maybe it is stuck there? But this would mean that when using COM you have to use a home-made lock class processing these parasite messages, instead of using MFC locks.
Anyway, I am still did not get anywhere. Any ideas?
-----------------** -- Posted from CodeGuru -- **-----------------
http://www.codeguru.com/ The website for Visual C++ programmers.