SendMessageCallback() - what is execution context of callback function

[Gorlash]

I have a technique that I use in WinAPI programs, to avoid stalling the message queue.

I start a separate thread in my program, which opens a hidden window with its own message queue. I typically call this thread the CommTask thread, since the first time I did this was to handle slow serial communications. When I want to perform a time-consuming task, I send a message to the CommTask thread using SendMessageCallback(), with a data packet telling it what to do.

When the CommTask thread completes handling of my message, my callback function gets executed.
What I don't know is, what thread is the callback function executing in?? Is it still in the CommTask thread, or has it some how returned to my main program thread, or is there some other thread context that it executes in?

[Igor Vartanov]

From MSDN:

Remarks

If the target window belongs to the same thread as the caller, then the window procedure is called synchronously, and the callback function is called immediately after the window procedure returns.
If the target window belongs to a different thread from the caller, then the callback function is called only when the thread that called SendMessageCallback also calls GetMessage, PeekMessage, or WaitMessage.

[OReubens]

Typically speaking... it is the thread that created the window that needs to handle messages for that window. This is what MSDN means when they say "the window BELONGS to a thread".
Trying to make it work otherwise is a recipe waiting for a disaster somewhere down the road.


Your description is vague, and I'm not even sure why you need to create a hidden window at all for this.
You can have a messageloop without a window, and you can post a message to a thread without that thread having a window, that's what PostThreadMessage() does.


It seems you're trying to solve things in a convoluted way, and probably the things you want to solve don't even need to be solved at all. The real hidden gem in the above answer is...
Do not use SEND mechanisms to another thread (or try to make something that appears to do that), use POST mechanisms, since that does not require synchrounous access to the other thread(s).
Sending will invariably lead to either some form of deadlock or lost 'messages'.

[Gorlash]

Thank you, Igor; I missed that paragraph in MSDN, thanks! That does directly answer the question.

OReubens: Yes, I've used (or tried to use) all of the methods that you suggest, and they all have issues, though it isn't of value to discuss them all here.

However, I would note that SendMessageCallback() has the same immediate effect as PostMessage(); it returns immediately, without waiting for the message to be handled. However, the Callback function gives the originating thread a way to take action once the message is eventually handled. I've been using it extensively, for years in many programs, and can assure you that it works Very efficiently.

[OReubens]

I know that function, but it has (a bunch of) issues of it's own. My main gripe with it is that it doesn't do what you probably expect it does and it has a double asynchronous behaviour that makes it unsuitable (or non-ideal) for common use cases.
I've seen it being used wrongly more than I've seen otherwise, which is why I generally recommend against it, if you need a post+feedback, then doing this explicitely will save you a couple headaches along the way.

The only case I know of where this function is appropriate is if the 2 threads belong to different processes, yoy don't have ownership of the process being sent to, and you need a way to know when the other process has processed the message.

[Gorlash]

Could you clarify what kind of issues you've seen with this function? I've been using it in our multi-threaded application for years now, under fairly heavy use, and am not aware of any issues with it (which certainly does not mean they aren't there!).

Originally I used a two-message system for this, where the main thread sent a message to the task-handler thread, and when the task-handler was done it sent another message back to the caller (both of these being user-defined messages), but SendMessageCallback() seems to accomplish the same job without requiring the second message, and I don't have to worry about special cases where I might miss sending the DONE message; with the latter function, the callback *always* gets executed...

(BTW, should this discussion be moved to a separate thread? My original question has already been answered elsewhere ( GetCurrentThreadId() in the callback function, showed me what thread it was executing in, that being the original caller thread.) )

[OReubens]

The issues typically involve around the fact that people don't quite understand how it works.
You say you've been using this for years, yet, you had a basic questions about it. Point proven ?

And also the fact you don't get control over when the callback gets called, in most apps this doesn't matter, on some apps it can cause really strange internal priority reversals.

Part of it is the fact the callback gets called by the mere call of peekmessage is imo the biggest mistake MS made with this. PeekMessage is supposed to be non-intrusive, yet, the callback gets called, which could make it being called at an unsafe time. Again, in most apps it probably doesn't matter, but it might very well be.

There's more, but it's an uncommon function as it is.
Overall if you can help it, a PostThreadMessage, and a Post back (either to window or as thread message) is the safer/better/more controllable way out.

There's a use for SendMessageCallback (see #5), I can't think of another 'good' one.

And BTW "might miss sending the done message", that's just a really poor excuse. It's the same poor excuses people have with new and "might forget delete". There's elegant C++ ways out of that (such as a run_something_at_end_of_function_scope object)


Sure it may work for you, but that's again, a bit of saying you drive your kid to school in in tank. Sure it has poor economy and it's a bit bulky to drive and difficult to park, but "it works" to get your kid to school. There's more elegant ways to do that.
And there's unfortunately reasons why tanks exist.