Some
system programs that never terminate execute an
event loop, going to sleep at the start of each cycle and waiting for some event to awaken them. Once an event is received, the program services the event, then returns to the beginning of the next wait cycle. Other programs periodically
poll for events by going to sleep and resuming execution after a specific interval of time. Once execution is resumed, the program polls for events or status changes, and then services any that occurred while it was asleep. After servicing the events, the program then goes to sleep again for the next time interval. Certain kinds of
heartbeat events or
keep-alive signals can be generated by these kinds of programs. The sleep() function call can be repeatedly called for short periods of time to slow the execution of a running program or code. Throttling code in this manner provides a coarse mechanism for mitigating the effects of overheating hardware or easing timing issues for legacy programs. The downside to cycling sleep and running states rather than leveraging cycle emulation (via an emulator) to control the execution speed of software is that interactive software will acquire a notable stutter if too little time is spent awake, too much time is spent sleeping, or a combination of both.
Uninterruptible sleep An uninterruptible sleep state is a sleep state that will not handle a signal right away. It will wake only as a result of a waited-upon resource becoming available or after a time-out occurs during that wait (if specified when put to sleep). It is mostly used by device drivers waiting for disk or network IO (input/output). When the process is sleeping uninterruptibly, signals accumulated during the sleep will be noticed when the process returns from the system call or trap. In Unix-like systems the command 'ps -l' uses code "D" for the uninterruptible sleep state of a process. Such processes cannot be killed even with
SIGKILL and the only non-sophisticated way to get rid of them is to reboot the system. == See also ==