Simple UNIX-process/thread model

Simple UNIX-process/thread model
Traditionally, UNIX tends to assign a task to a process for full acceptance, but a task is not just an execution thread, for example, all the members of a company are doing the same thing, everyone is only responsible for a part. After the granularity is reduced, everything can be done at the same time. In any case, everyone shares all the resources. Therefore, a thread occurs. Threads are actually different threads that share resources. The thread semantics is different from the plain UNIX process.
0. original Process model-the famous fork calls simple UNIX processes rely on the famous fork call, that is, this fork call makes the UNIX process and the Windows process completely different, it is precisely because of this fork call, there is no room for compatibility between the two. This fork call has a long history. As early as in the large operating system before UNIX, it existed. In the first 1969 of UNIX, fork was not actually called. At that time, two fixed processes were connected to two terminals. After the fork call is introduced, the number of processes increases rapidly. Note that no exec call is yet available!
1. at the beginning of UNIX, the UNIX process model had the same concept as its prehistoric predecessors. At that time, the file system was quite immature, programmers focus on executing tasks that are not easy to write, rather than writing tasks themselves (first, there is not that big demand, and second, information storage is a problem, without the Internet, compare the current AppStore ...). Fork calls directly organize UNIX processes into trees, so:
The swap/sched process No. 1.0 and init process No. 1 have a special position;

Fork + exec.
2. The process model that provides the resource environment, Windows NT, has used the UNIX idea in many aspects, but adopts a completely different idea in the process model. Windows NT was born in the 1990 s, and its applications began to blossom everywhere, and its file systems were very mature, the concept of executable files continues from the MS-DOS era (in fact, the UNIXv6 version has the concept of executable files, after the introduction of exec UNIX call, executable files are only the backup resources of the process, only that.) people can develop a large number of different programs based on Win32 APIs and run them separately. If you want to run a program multiple times, click it several times.
3. reconciliation of the two models first, conflicts between the fork model and the resource model are obvious, typically reflected in the following two aspects:
1. Signal problem: Which thread executes signal processing;

Scheduling entity, scheduling entity group, process group, session...
Int clone (int (* fn) (void *), void * child_stack, int flags, void * arg ,... /* pid_t * ptid, struct user_desc * tls, pid_t * ctid */);
4. Linux's thread support for implementing the UNIX Process Model in Linux is very handsome. It hardly touched any existing task_struct struct, nor changed any existing fork semantics. It only introduces a PID type called TGID, that is, the process group ID. In Linux, the executable object is task_struct, and only task_struct. Each task_struct has more than one ID. The task_struct is located to a process or a thread of a process according to the different interpretation methods of these IDs. The ID type is as follows:
Enum pid_type {PIDTYPE_PID, PIDTYPE_TGID, PIDTYPE_PGID, PIDTYPE_SID, PIDTYPE_MAX };
PIDTYPE_PID: Scheduling entity ID. If task_struct is the thread of a process, it is the thread ID. If the process only has a unique thread, it is also the process ID;
PIDTYPE_TGID: the ID of the thread set. If the process to which the task_struct belongs has multiple threads, it is the process ID. If there is only one thread, it is equivalent to PIDTYPE_PID;
PIDTYPE_PGID: Process Group ID. Not explained;
PIDTYPE_SID: Session ID. Not explained.
1. Each task_struct has a unique ID Identifier in the PID namespace. during initialization, it is assigned to both the process ID and thread ID;

If you understand the figure above, you will understand how handsome Linux is in implementing the UNIX process model. Such a streamlined model is exactly the same as Linux's so streamlined implementation. I don't know why traditional UNIX has attracted so much complexity... linux has a clear insight into the hierarchical structure of the UNIX process model, namely process, process group, and session. If another layer is extended, task_struct is moved down to the bottom layer, the above picture is basically drawn.
5. dennis. speaking back to the development history of UNIX, Ricky finally said a paragraph, which is simply from the mouth of the poet. This poetic style can only be expressed by true feelings and true temperament. It can be seen that Dennis. how special is Ricky's feelings for UNIX:
One of the comforting things about old memories is their tendencyto take on a rosy glow. the programming environment provided by the early versions of Unix seems, when described here, to be extremely harsh and primitive. I am sure that if forced back to the PDP-7 I wocould find it too lerably limiting andlacking in conveniences. nevertheless, it did not seem so at the time; the memory fixes on what was good and what lasted, and on the joy of helpingto create the improvements that made life better. in ten years, I hope we can look back with the same mixed impressionof progress combined with continuity.