PRB: Message Broadcasting Process Causes Deadlock

MORE INFORMATION

To receive notification when a process has terminated, a Win32 application may call WaitForSingleObject() and specify the process handle of the application to be waited on. Normally, this will cause the waiting process to block until the application being waited on terminates. Then WaitForSingleObject() will return WAIT_OBJECT_0 and the waiting process will continue to execute.

Sometimes applications broadcast messages to some or all other windows on the system. In this event the above method will cause a deadlock situation if the waiting application is not free to process messages. If the waiting application is waiting in its thread that processes window messages, then no messages can be processed until the wait is complete. If the process waited on calls SendMessage() and broadcasts a message to the window of the waiting process, then a deadlock results. The SendMessage() will not return until the message is processed, and the waiting process cannot dispatch the message until its WaitForSingleObject() call returns. For a description of a common OLE manifestation of this problem, please refer to the following Knowledge Base article: To prevent this deadlock, the waiting application should wait in a separate thread, thus freeing the main thread to process messages. When the process that is being waited on completes and WaitForSingleObject() returns, the waiting thread can notify the main thread by sending a user-defined message to the message queue of the main window. The main thread will interpret the user-defined message as completion of the waited-on process. For more information about user-defined messages, please refer to the following Knowledge Base article: Another way to avoid this problem is to have the waiting thread call MsgWaitForMultipleObjects() in a loop, which calls DispachMessage() when a message needs to be processed. For an example of this technique see the Knowledge Base article referenced above on the OLE problem (Q136885).