WinAPI wrapper classes

This is a discussion on WinAPI wrapper classes within the Windows Programming forums, part of the Platform Specific Boards category; Hey all, I've heard it said that ideally a Win32 app's message pump should be placed in a separate thread. ...

  1. #1
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879

    WinAPI wrapper classes

    Hey all, I've heard it said that ideally a Win32 app's message pump should be placed in a separate thread. However, from my point of view this would create far more problems than it would solve.

    -You would have to create/initialize the window from the worker thread: more work for you.
    -You would have to worry about thread synchronization whenever responding to events such as a button click, repaint, keyboard, etc.: more headache for you.
    -You would have to worry about init and cleanup of a thread, rather than just terminating the message loop and quitting: more work for you.
    -Unless you thread sync, virtually nothing can be done in the original thread; But if the GUI thread is waiting on a sync object while your main thread does something slowly, you've just lost any potential benefit.
    -You can reproduce much the same effect by placing mini-messagepumps in your functions that block.

    The only advantage I can think of, is in the event of you wanting to use GetMessage() and another non-user-defined blocking function at the same time; but few functions (Winsock excluded) will block for a noticeable amount of time, and if polling/asynchronous is an option (like in Winsock ) then you can switch to "PeekMessage(), then poll other", with a Sleep(1); thrown in there to prevent eating all the CPU time.

    Can anyone give me a better, solid example of why you'd want to separate your message loop from your main thread?

    Thanks.
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  2. #2
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,699
    >> -You would have to create/initialize the window from the worker thread: more work for you.
    True, but work you'd have to do anyways.

    >> -You would have to worry about thread synchronization whenever responding to events such as a button click, repaint, keyboard, etc.: more headache for you.
    Not typically. These are the responsibilities of a message-loop thread and there shouldn't be other threads interfering with these responsibilities.

    >> -Unless you thread sync, virtually nothing can be done in the original thread
    There's nothing wrong with two threads doing something at the same time as long as the threads synchronize when needed.

    >> -You can reproduce much the same effect by placing mini-messagepumps in your functions that block.
    True.

    Most of the time you can write your Windows apps so that the main thread takes care of the message loop for the entire application - and any created threads perform processing in the background.

    Sometimes it makes sense to seperate a window or group of windows into a seperate UI message-loop thread. A good example would be an MDI implementation like the one Excell and MS-Word use - in that each open document gets it's own UI thread which is responsible for an open document window on the taskbar.

    gg

  3. #3
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    >>Not typically. These are the responsibilities of a message-loop thread and there shouldn't be other threads interfering with these responsibilities.
    Right, but GUI events typically signify:
    -You want the program to do something -> access data that the main thread is using
    -You want the program to display data -> access data that the main thread is modifying
    If the window procedure has to display data that the main thread is using, i.e. tying up with a blocking operation, then we've still got a message clog as we wait for the main thread to finish up and release control; and if a buttonclick is supposed to trigger a lengthy operation, then we'll have a message clog again (especially if the button event also needs access to that data we're sitting on). Unless, I suppose you might just spawn another worker thread to handle the buttonclick?

    The MDI example makes more sense to me though, since each window/thread acts as more or less an independent, self-contained application with little or no data sharing; and the main thread just acts as the glue and slavedriver, sticking them all together and telling them to open or close.
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  4. #4
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,699
    If you have to wait for access to a resource not under your control then there's not much you can do except show a "pleas wait" dialog with a cancel button to the user.

    Shared resources will have to be synchronized with respect to thread access, but any "clogs" that occur between your own threads are usually the programmers fault.

    >> then we've still got a message clog as we wait for the main thread to finish up and release control
    So in this situation, the clog occurs because who ever implemented the main thread is hog'n resources for too long (I say "too long" because anything less wouldn't be a "clog").

    Use a worker thread when you want to perform a background task asynchronous to user input or any other message.
    Use a GUI thread when you want to dedicate a message pump to one ore more windows in your application.

    gg

  5. #5
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    >>Use a worker thread when you want to perform a background task asynchronous to user input or any other message.
    Sounds good

    >>when you want to dedicate a message pump to one or more windows in your application.
    Isn't that the same thing as "Use a GUI thread when you want to put the message pump for a window in a separate thread"?
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  6. #6
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,699
    Yes, that's the same thing.

    >> I've heard it said that ideally a Win32 app's message pump should be placed in a separate thread.
    I wouldn't say it's "ideal", but using GUI threads does have its place. Personally, I tend to solve most problems using a single GUI thread and zero or more worker threads.

    Regardless of how many GUI threads you have, each GUI thread needs to stay responsive to user input. If processing a message takes "too long" such that user input is ignored or delayed, then that processing might belong in a worker thread.

    gg

  7. #7
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    >>Yes, that's the same thing.
    And circular logic is good because it is

    By 'a single GUI thread', are you referring to your main thread, or do you still spawn a separate thread for your GUI?

    >>Regardless of how many GUI threads you have, each GUI thread needs to stay responsive to user input. If processing a message takes "too long" such that user input is ignored or delayed, then that processing might belong in a worker thread.
    Sounds logical.
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  8. #8
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,699
    Yes, I was refering to the main()/WinMain() thread as the primary GUI thread.

    gg

  9. #9
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    Ok, thanks
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Wrapper classes
    By Know_Your_Role in forum C++ Programming
    Replies: 17
    Last Post: 06-10-2009, 02:24 AM
  2. OOP Question DB Access Wrapper Classes
    By digioz in forum C# Programming
    Replies: 2
    Last Post: 09-07-2008, 05:30 PM
  3. Working with winAPI in classes (newbie question)
    By Spyril in forum Windows Programming
    Replies: 3
    Last Post: 11-09-2007, 03:21 PM
  4. WinAPI Wrapper and WndProc
    By Lurker in forum Windows Programming
    Replies: 2
    Last Post: 04-19-2004, 09:34 PM
  5. wrapper classes?
    By curlious in forum C++ Programming
    Replies: 6
    Last Post: 08-27-2003, 10:26 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21