A computer program (process, task, or thread) may sleep, which places it into an inactive state for a period of time.
The parameter typically specifies seconds, although some operating systems provide finer resolution, such as milliseconds or microseconds.
[6] In Windows API: In Unix or POSIX system calls: Sleep causes the thread or process to give up the remainder of its time slice and stay in the Not Runnable state for the specified duration.
On POSIX systems, the nanosleep and related syscalls are interruptible by signals, returning the remaining sleep time.
The sleep library function, on the other hand, is implemented via the alarm syscall on many older systems, thus it only works by delivering a signal.
Throttling code in this manner provides a coarse mechanism for mitigating the effects of overheating hardware[7] 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.