4

Simple task: Send a windows message with dynamically allocated data, e.g. an arbitrary length string. How would you manage the responsibility to free this data?

The receiver(s) of the windows message could be responsible to free this data. But: How can you guarantee that all messages will actually be received and thus the linked data will be freed? Imagine the situation that the receiver is shutting down, so it won't process it's message queue any more. However, the message queue still exists (for some time) and can still accept messages, which won't be processed any more.

Thanks!

user9876
  • 10,954
  • 6
  • 44
  • 66
nang
  • 421
  • 6
  • 16
  • For the bounty, assume the message is being posted with PostMessage(). I'm not using SendMessage because that would make the question trivial (and also because the thing doing the posting is a worker thread that can't call SendMessage, because it doesn't own the window). – user9876 Feb 01 '11 at 18:32
  • can you edit the question so that it actually asks what you want answered. What's more it is perfectly safe to call SendMessage in this situation. – David Heffernan Feb 01 '11 at 19:30
  • @user9876 Which messages are you talking about? I have a hunch that messages that take pointer parameters are not allowed to be posted. – David Heffernan Feb 02 '11 at 19:43
  • If you are that concerned about it, why not store a pointer to the data in some container and have the receiver respond to you when he's done with it? Of course this suffers from the opposite problem; if the receiver is shutting down and never responds, you're not going to free that memory until you shutdown (but at least you won't leak it). – Luke Feb 04 '11 at 21:44

2 Answers2

2

PostMessage returns a BOOL that tells you whether the message was posted or not. This is usually good enough, because your window should be valid until it receives the WM_DESTROY and the WM_NCDESTROY messages. After a call to DestroyWindow (which sends these messages) you should not be able to successfully call PostMessage again.

Now, if your PostMessage returns FALSE you have to clean up. If it doesn't, the window procedure has to clean up. Don't send messages that have to be cleaned up to random windows that might not handle them. Actually, don't send any WM_USER + x messages to any windows you don't handle.

Fozi
  • 4,973
  • 1
  • 32
  • 56
1

There's nothing to do here. As soon as the call to SendMessage returns, you can free the data. As it happens, the other app isn't looking at your memory anyway since it's in a different process. Instead Windows marshals the data across the process boundary.

What's more, if you are receiving the data in a WndProc, you can't take a copy of the pointer to the string. Instead you must take a copy of the contents of the string since that pointer is only valid for the duration of that call to WndProc.

The other point to make is that you have a confusion about the message queue. When you send a message, that happens synchronously and the queue is not involved. The message queue is where posted messages are placed. They are process asynchronously.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • Assume I'm using PostMessage(), not SendMessage(). Also, the window is in the same process but it's owned by a different thread. – user9876 Feb 01 '11 at 18:33