The Linux Programming Interface says
22.3 Interruptible and Uninterruptible Process Sleep States
We need to add a proviso to our earlier statement that SIGKILL and SIGSTOP always act immediately on a process. At various times, the kernel may put a process to sleep, and two sleep states are distinguished:
TASK_INTERRUPTIBLE : The process is waiting for some event. For example, it is waiting for terminal input, for data to be written to a currently empty pipe, or for the value of a System V semaphore to be increased. A process may spend an arbitrary length of time in this state. If a signal is generated for a process in this state, then the operation is interrupted and the process is woken up by the delivery of a signal. When listed by ps(1), processes in the TASK_INTERRUPTIBLE state are marked by the letter S in the STAT (process state) field.
TASK_UNINTERRUPTIBLE : The process is waiting on certain special classes of event, such as the completion of a disk I/O. If a signal is generated for a process in this state, then the signal is not delivered until the process emerges from this state. Processes in the TASK_UNINTERRUPTIBLE state are listed by ps(1) with a D in the STAT field.
So it says that a process in TASK_INTERRUPTIBLE state is waiting for some event, and is woken up by the delivery of a signal generated for the process.
What is the relation between an event awaited by the process and a signal which wakes up the process? Must the signal signifies the occurrence of the event? Or can the signal be unrelated to the event?
Is a process in TASK_INTERRUPTIBLE state waken up only by the delivery of a signal?
For example, when a process calls
waitpid() to wait for the termination of any child process,
- does its state become TASK_INTERRUPTIBLE?
- what can make the call to
wait()/waitpid()return? Is it only the delivery of SIGCHLD? When a child terminates, does that necessarily generate SIGCHLD and deliver it to the process?