One of the ‘task_struct’ field is ‘state‘ which says the ‘state’ of this process..
I see there are 2 types of ‘states’, it can be either ‘state’ or ‘exit_state’
task->state is about ‘runnability‘..
task->exit_state is about ‘task exiting’
One of the flags in ‘state’ will be set and ‘state’ flags are mutually exclusive..
task->state flags are:
[terminal]
#define TASK_RUNNING 0
#define TASK_INTERRUPTIBLE 1
#define TASK_UNINTERRUPTIBLE 2
#define __TASK_STOPPED 4
#define __TASK_TRACED 8
#define TASK_DEAD 64
#define TASK_WAKEKILL 128
#define TASK_WAKING 256
task->exit_state flags are:
#define EXIT_ZOMBIE 16
#define EXIT_DEAD 32
[/terminal]
ABOUT task->state runnability flags:
*) TASK_RUNNNING
A process with ‘TASK_RUNNING’ state means that the process is runnable, and it is either currently running or on a run queue waiting to run. This is the only possible state for a process executing in userspace. it can also apply to a process in kernel space that is actively running. That said, this process is either executing on CPU or waiting for the CPU to execute.
*) TASK_INTERRUPTIBLE
The process is suspended (sleeping) until some condition becomes true. Events like hardware interrupt, signal delivery, released system resources can wake up the process and change the status back to TASK_RUNNING. Processes in idle mode (ie not performing any task) should be in this state.
*) TASK_UNINTERRUPTIBLE
Like “TASK_INTERRUPTIBLE”, a signal delivery is not honored with the process is in TASK_UNINTERRPTIBLE” state. An example would be a process performing an atomic write operation.
The TASK_INTERRUPTIBLE and TASK_UNINTERRUPTIBLE indicate that the task is a wait state. Tasks at TASK_INTERRUPTIBLE state can be interrupted and wake up by an interrupt or a signal and will be returning to state TASK_RUNNING. Tasks at TASK_UNINTERRUPTIBALE must be explicitly waked up by an event. e.x. a task waiting for the data transferred from block dev to buffer.
TASK_INTERRUPTIBLE OR UNINTERRUPTIBLE processes are in wait queues. The task_structs which hold states either of these can be in wait queues..
[terminal]
struct __wait_queue_head {
spinlock_t lock;
struct list_head task_list;
};
typedef struct __wait_queue_head wait_queue_head_t;
[/terminal]
These are the processes waiting for an event to finish, system resource to be released, fixed interval of time to be
elapsed..
* ) TASK_STOPPED :
Process execution has been stopped; The process received any of ‘SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU’ signals.
SIGSTOP 17,19,23 Stop Stop process
SIGTSTP 18,20,24 Stop Stop typed at tty
SIGTTIN 21,21,26 Stop tty input for background process
SIGTTOU 22,22,27 Stop tty output for background process
*) TASK_TRACED
The subjected process has been traced by a debugger. Execution has been stopped by a debugger (ex: gdb ): When debugged each signal may put the process in this state.
2 possible states in task->exit_state.
1) EXIT_ZOMBIE:
Zombie processes are also called “defunct” processes in the system. Those are processes whose execution is completed, but the parent is not aware of it or parent didn’t reap its child, so it holds an entry in process table. It will not waste any other resources in the system. The only resource it wastes is the entry in the process table. It becomes an issue only when we/system reaches the situation: “The total no of processes running in the system is equal to the max limit of number of processes”. Then we may worry about them. The main chance for zombie creation is when a parent didn’t wait() for this child, in other words crappy application developers can generate a zombie process.
On the other hand, if the parent dies first, init (process 1) inherits the child and becomes its parent.
2) EXIT_DEAD:
This state comes to a picture when there is a transition happening from EXIT_ZOMBIE. The process is being removed by the system as the parent called wait ().
I hope it helps.