4

What happens when a window is destroyed while there are still messages pending for it?

Consider the following scenario:

There are three threads, A, B, and C. Thread C owns a window.

Threads A and B use SendMessage to post messages to the window. The message from A arrives first. While C is processing the message from A, it destroys its window using DestroyWindow.

What happens to the message from thread B? Does the call by thread B to SendMessage return?

How does this work internally?

Harry Johnston
  • 35,639
  • 6
  • 68
  • 158
user1482045
  • 41
  • 2

2 Answers2

1

According to MSDN, DestroyWindow "[...], flushes the thread message queue, [...]". I was not sure whether this meant processing the messages or dumping them, so I tried. It turned out to be the latter: all pending posted messages are removed from the queue and ignored. As for non-queued messages: in my tests the pending SendMessage call returned and set the last error to ERROR_INVALID_PARAMETER - 87 (0x57).

kicsit
  • 483
  • 5
  • 9
  • Interesting, but I wouldn't rely on this behaviour. There is likely to be a race condition, i.e., the results may well depend on the exact order in which the three threads are scheduled, so it might do one thing 99.9% of the time and something different the other 0.1%. – Harry Johnston Nov 05 '12 at 22:55
  • Now that I think of it, my point may have been moot; surely sending a message via a window handle that may have already been destroyed is inherently invalid? – Harry Johnston Nov 09 '12 at 00:21
  • http://stackoverflow.com/questions/7055869/are-window-handles-unique-or-do-they-ever-get-reused – Harry Johnston Nov 09 '12 at 00:26
  • DestroyWindow does not dump all the messages. It dumps only the messages specific to that window. If suppose C has owned multiple windows, DestroyWindow will not flush the threads message queue. only the particular windows messages are removed.. So I think MSDN is not clear. – user738471 Dec 07 '13 at 02:25
1

In principle, what you're proposing to do isn't safe. There's no way for thread C to guarantee that thread B has already sent the message; if the window is destroyed before thread B sends the message, and if the window handle happens to get reused in the meantime, thread B might wind up sending the message to the wrong window, which might be in a different application.

The best practice would be to make sure that all threads have been informed that a particular window handle has become invalid before calling DestroyWindow.

However, practically speaking, the risk of the handle being reused at just the wrong time is very low. If it is not plausible to inform the other threads ahead of time, you are unlikely to get into trouble as a result. I believe that kicsit is right in asserting that the message will not end up waiting in thread C's message queue, although the documentation does not explicitly promise this as far as I can tell.

Harry Johnston
  • 35,639
  • 6
  • 68
  • 158