SendMessageCallback() - what is execution context of callback function
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 7 of 7

Thread: SendMessageCallback() - what is execution context of callback function

  1. #1
    Join Date
    Feb 2014
    Posts
    5

    Question SendMessageCallback() - what is execution context of callback function

    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?

  2. #2
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    5,977

    Re: SendMessageCallback() - what is execution context of callback function

    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.
    Best regards,
    Igor

  3. #3
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    3,891

    Re: SendMessageCallback() - what is execution context of callback function

    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'.

  4. #4
    Join Date
    Feb 2014
    Posts
    5

    Re: SendMessageCallback() - what is execution context of callback function

    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.
    Last edited by Gorlash; May 8th, 2014 at 10:08 AM.

  5. #5
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    3,891

    Re: SendMessageCallback() - what is execution context of callback function

    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.

  6. #6
    Join Date
    Feb 2014
    Posts
    5

    Re: SendMessageCallback() - what is execution context of callback function

    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.) )
    Last edited by Gorlash; May 9th, 2014 at 12:04 PM.

  7. #7
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    3,891

    Re: SendMessageCallback() - what is execution context of callback function

    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.
    Last edited by OReubens; May 9th, 2014 at 04:09 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center