To manage processes, the kernel must have a clear picture of what each process is doing. It must know, for instance, the process's priority, whether it is running on CPU or blocked on an event, what address space has been assigned to it, and so on. This is the role of the process descriptor (a task_struct type structure whose fields contain all the information related to a single process).

The state field of the process descriptor describes what is currently happening to the process. It consists of an array of flags, each of which describes a possible process state. The following are the possible process states:


The process is either executing on a CPU or waiting to be executed.


The process is suspended(sleeping) until some condition becomes true. Raising a hardware interrupt, releasing a system resource the process is waiting for, or delivering a signal are examples of conditions that might wake up the process(put its state back to TASK_RUNNING)


Like TASK_INTERRUPTIBLE, except that delivering a signal to the sleeping process leaves its state unchanged. This process stage is seldom used. It is valuable, however, under certain specific conditions in which a process must wait until a given event occurs without being interrupted. For instance, this state may be used when a process opens a device file and the corresponding device driver starts probing for a correspoding hardware device. The device driver must not be interrupted until the probing is complete, or the hardware device could be left in an unpredctable state.


Process execution has been stopped; the process enters this state after receiving a SIGSTOP,SIGTSTP,SIGTTIN, or SIGTTOU signal.


Process execution has been stopped by a debugger. When a process is being monitored by another, such as when a debugger executes a ptrace() system call to monitor a test program, each signal may put the process in the TASK_TRACED state.


Process execution is terminated, but the parent process has not yet issued a wait4() or waitpid() system call to return information about the dead process. Before the wait() like call is issued, the kernel cannot discard the data contained in the dead process descriptor because the parent might need it.


The final state: the process is being removed by the system because the parent process has just issued a wait4) or waitpid() system call for it. Changing its state from EXIT_ZOMBIE to EXIT_DEAD avoids race conditions due to other threads of execution that execute wait() like calls on the same process


Note: The last two states are additional states, they can be stored both in the state field and in the exit_state field of the process descriptor; as the field name suggests, a process reaches one of these two states only when its execution is terminated.


Comments powered by CComment