[Z] Two main thread features

Link to this article:Http://www.titilima.cn/show-544-1.html
First look at a piece of citation, the source is not clear, but it must be a paper publication.

 

>ProgramThe thread that is executed after startup is called the primary thread. The main thread has two
> Features. First, itRequiredResponsible for the main message circulation in the graphic user interface (GUI) Program
> Ring. Second, the end of this thread (either becauseBecause exitthread () is called ()) Yes
> So that all threads in the program are forced to end and the program ends. Other threads have no chance
> Perform cleanup.

When I read a book, I often only know a rough sentence, and a sentence like this is basically something I ignore. However, at an accidental opportunity, I noticed this sentence and had the following comments.

Conclusion: The two features of the main thread mentioned in the sentence are basically unreliable.

> First, itRequiredResponsible for the main message loop in the graphic user interface program.
The reason why this statement is unreliable is that it excessively limits the functions of the main thread. In my impression, in versions earlier than 4.0, the main thread is a scheduler used to schedule other worker threads, the UI thread is also one of these worker threads. In other words, the main message loop may not be in the main thread.

> Second, the end of this thread (whether it is returned orBecause exitthread () is called ()All threads in the program are forced to end, and the program ends.
This is a half-to-half error, because if exitthread is called in the main thread, other threads will not exit, so the program will not end. Consider the followingCode:

C ++ code

2. # Include <windows. h>
6. DWORDWinapi threadproc (PvoidParam)
8. {
10. For(;;)
12. {
14. Sleep (1000 );
16. }
18. Return0;
20. }
24. IntMain (Void)
26. {
28. HandleHthread = createthread (null, 0, threadproc, null, 0, null );
30. Sleep (1000 );
32. Exitthread (0 );
34. Return0;
36. }

After the program runs, the main thread is terminated by exitthread, but the threadproc thread runs continuously. The following is a good explanation of this question in the Windows programming notes.

---------- The legendary separation line ----------

So, let's explore the normal process of Process Termination. To avoid unnecessary code interference, I chose an empty skeleton program.

C ++ code

2. # Include <windows. h>
6. IntWinapi winmain (
8. HinstanceHinstance,
10. HinstanceHprevinstance,
12. LpstrLpcmdline,
14. IntNshowcmd)
16. {
18. Return0;
20. }

As you can see, this program is really worthy of the title of "skeleton"-it is really a shelf except for bones.
On the surface, this winmain is the entry of the program. When it returns (return 0;), our process ends. Of course, the fact is certainly not as simple as it seems, because the compiler is very happy to secretly do good things, and there is still a habit of refusing to leave a name when doing good things.
Now let's compile this code and use windbg to debug this program. We do not set any breakpoints, so the program runs until the end. At this time, the call stack information of the program will look like the following:

Windbg output

2. 0: 000> K
4. Childebp retaddr
6. 0012fdc4 7c92e89a NTDLL! Kifastsystemcallret
8. 0012fdc8 7c81ca3e NTDLL! Zwterminateprocess + 0xc
10. 0012fec4 7c81ca96 Kernel32! _ Exitprocess + 0x62
12. 0012fed8 004012a1 Kernel32! Exitprocess + 0x14
14. 0012fee4 0040148d skeleton! _ Crtexitprocess + 0x17
16. 0012ff28 004014b7 skeleton! Doexit + 0x113
18. 0012ff3c 0040114f skeleton! Exit + 0x11
20. 0012ffc0 7c816ff7 skeleton! _ Tmaincrtstartup + 0x121
22. 0012fff0 00000000 Kernel32! Baseprocessstart + 0x23

The truth is finally revealed in the world. Obviously, the compiler hides the exitprocess API of kernel32.dll behind winmain, so that our skeleton.exe process can exit. If you are interested in how to encapsulate exitprocess details, you can take a deeper look at the C RuntimeSource codeCrt0.c file in.

---------- The legendary separation line ----------

Obviously, the execution of exitthread causes the thread to end, that is, the exitprocess In the CRT is skipped directly, so that the process cannot end.