A ramble on windows and threads

Why talk about Windows and threads

The discussion is still related to the previous project experience. For the time being, the project is a project. A project includes a client and a server, the client has a core network module, the network module based on the completion of port development, there are multiple worker threads, the network module is responsible for receiving data from the server, processing the data, and the final processing results displayed on the window. So the question is, how do the worker threads display the results of the final processing of the data on the window? It can be said that this problem is not only a problem in the project A, most Web applications will encounter this problem. The scenario in a project at that time was to use the window handle in a worker thread to directly invoke the corresponding function (such as SendMessage) to manipulate the window. Although this practice did not have problems at the time? But is it really no problem? If there is a problem, how do we show the final processing results on the window?

window and thread relationships

Theoretical knowledge is the basis for us to answer the above questions. The only information I've found in this area is the Windows Core Programming 26th window message. For this brother who is not quite clear, you can look at it first. We're not going to go into detail here.

Using window handles in a worker thread to directly invoke the appropriate function to manipulate the window.

In the vast majority of cases, the problem does not occur. But only in the vast majority of cases, the following are the two situations where the problem occurs.

1. This is a situation I personally experienced in project A. I called the SetFocus function in the worker thread, and the function did not return successfully, why? The following is a description in the SetFocus documentation.

   Sets the keyboard focus to the specified window. The window must is attached to the calling thread ' s message queue.

   The reason for this is that the window handle passed to the SetFocus function represents the window that must belong to the thread that called the SetFocus function, but the worker thread does not own the window or owns any windows. So why call the Setfoucs function to have this requirement? This can only be said I am not very clear, but in conjunction with "Windows core programming" in the 26th chapter of the relevant description, each thread has its own keyboard focus, should be to some extent answer this question.

2. This situation is mentioned in the article "main interface security in multithreaded programming," which is roughly the case that a thread that owns a window is waiting for the worker thread to exit, and the work line is impersonating blocked in the SendMessage call to the window. It should be said that this situation is not impossible to happen.

That's all I'm saying. It is not recommended to use window handles directly in a worker thread to invoke a related function on a window process, although this practice does not go wrong in the vast majority of cases, but when problems occur, it is more difficult to troubleshoot them. But I do not completely deny this approach, provided that the programmer itself must be aware of the logic of the program itself, such as in the worker thread will not invoke such a function like SetFocus, will not appear in the second case mentioned above.

How the worker thread displays the final processing results to the window

Since it's not a good practice to call a related function directly in a worker thread through a window handle, what is the way to display the final processing results to the window? My approach is to call PostMessage, which passes the data to the Window's window procedure processing by customizing the message, that is, the thread handling that owns the window, in which case the only window-related action in the worker thread is to invoke PostMessage through the window handle. At present, I do not think there is any problem with this practice, if someone feels that there is a problem, we can discuss it together.

In addition, if there are brothers who know better practices, we can also discuss them.

Feel and think

In the process of locating threads and windows, many people are asking questions about threads and windows, discussing some concepts about windows and threads, and doing something very iffy. But actually figuring out some basics and thinking for yourself, these questions are not difficult to answer. Perhaps MFC is a little more convenient than the traditional Win32 API, but some basic concepts such as window procedures, message loops, etc., are still to be understood.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

A ramble on windows and threads