About GUI threads and worker threads

1. The so-called worker thread is a thread that does not involve a graphical user interface (GUI) purely as an operation.

2. Microsoft's Multithreaded Model:
The Win32 documentation repeatedly emphasizes that threads are divided into GUI threads and worker threads. The GUI thread is responsible for building the window and processing the main message loop. The worker is responsible for performing purely computational work, such as recalculating or re-editing pages, which can cause the message queue of the main thread to lose its response. In general, GUI threads never do work that can't be done right away.
A GUI thread is defined as a thread that owns a message queue. Any message from a particular window is always caught and processed by the thread that generated the window. All changes to this window should also be done by the thread.
If a worker thread also produces a window, then a message queue is generated and attached to the thread, and the worker thread becomes a GUI thread. This means that the worker thread cannot produce a window, dialog box, message box, or any other UI-related thing.
If a worker thread needs to enter or output an error message, it should authorize the UI thread to do it and notify the worker thread of the result.
Message Queuing is a list of elements that are generated only when necessary. Specific data structures for Message Queuing can be referenced in the relevant Windows documentation.

3. In Win32, each thread has its own proprietary message queue. This does not mean that every window has its own message queue, because a thread can produce many windows. If a thread stops responding, or if it is busy with a time-consuming computation, the resulting window stops responding, but other windows in the system continue to work.
Here is a very basic rule to manage the interaction of threads, messages, and windows in Win32:
All messages sent to a window will be handled by the thread that generated the window.
For example, using SetWindowText to update the contents of an edit box is actually sending out a wm_settext message to the edit window function. By and by, each control is a window that has its own window function.
Everything that is done to the window is basically handled by the Window's window function and is therefore generated by the window's threading.

When a message needs to be sent, Windows automatically calculates which thread should receive the message (in order to determine which thread's message queue the message entity should be hanging on). At the same time, Windows determines how threads should be told that a message came in. A total of four possible:
(1) If you are on the same thread and use SendMessage to pass the message, call the window function directly.
(2) If the same thread is used to deliver the message using PostMessage, the message is placed in the message queue and returned immediately.
(3) If you do not belong to the same thread and use SendMessage to pass the message, switch to the new thread and call the window function. SendMessage does not return until the window function finishes.
(4) The PostMessage returns immediately, and the message is placed in the message queue of another thread.
When I send a message to another thread to master the window, the system must do a context switch, switch to another thread, call the window function, and then do a context switch back, relative to the general function calls, the additional burden during the period is greater. If you assign a thread to each child window in the MDI, all the resources of that child window-including the brush, DC, palette, and so on-belong to the thread's resources. It can be costly to do a context switch for a thread at this point.

About GUI threads and worker threads