1SLEEP(3P)                  POSIX Programmer's Manual                 SLEEP(3P)
2
3
4

PROLOG

6       This  manual  page is part of the POSIX Programmer's Manual.  The Linux
7       implementation of this interface may differ (consult the  corresponding
8       Linux  manual page for details of Linux behavior), or the interface may
9       not be implemented on Linux.
10

NAME

12       sleep — suspend execution for an interval of time
13

SYNOPSIS

15       #include <unistd.h>
16
17       unsigned sleep(unsigned seconds);
18

DESCRIPTION

20       The sleep() function shall cause the calling  thread  to  be  suspended
21       from execution until either the number of realtime seconds specified by
22       the argument seconds has elapsed or a signal is delivered to the  call‐
23       ing thread and its action is to invoke a signal-catching function or to
24       terminate the process. The suspension time may be longer than requested
25       due to the scheduling of other activity by the system.
26
27       In single-threaded programs, sleep() may make use of SIGALRM. In multi-
28       threaded programs, sleep() shall  not  make  use  of  SIGALRM  and  the
29       remainder of this DESCRIPTION does not apply.
30
31       If  a SIGALRM signal is generated for the calling process during execu‐
32       tion of sleep() and if the SIGALRM signal is being ignored  or  blocked
33       from  delivery,  it  is  unspecified  whether  sleep() returns when the
34       SIGALRM signal is scheduled. If the signal is being blocked, it is also
35       unspecified  whether  it remains pending after sleep() returns or it is
36       discarded.
37
38       If a SIGALRM signal is generated for the calling process during  execu‐
39       tion  of sleep(), except as a result of a prior call to alarm(), and if
40       the SIGALRM signal is not being ignored or blocked from delivery, it is
41       unspecified  whether  that  signal  has  any  effect other than causing
42       sleep() to return.
43
44       If a  signal-catching  function  interrupts  sleep()  and  examines  or
45       changes  either  the  time  a SIGALRM is scheduled to be generated, the
46       action associated with the SIGALRM signal, or whether the SIGALRM  sig‐
47       nal is blocked from delivery, the results are unspecified.
48
49       If a signal-catching function interrupts sleep() and calls siglongjmp()
50       or longjmp() to restore an environment saved prior to the sleep() call,
51       the  action  associated with the SIGALRM signal and the time at which a
52       SIGALRM signal is scheduled to be generated  are  unspecified.   It  is
53       also unspecified whether the SIGALRM signal is blocked, unless the sig‐
54       nal mask of the process is restored as part of the environment.
55
56       Interactions between sleep() and setitimer() are unspecified.
57

RETURN VALUE

59       If sleep() returns because the requested time has  elapsed,  the  value
60       returned  shall  be  0. If sleep() returns due to delivery of a signal,
61       the return value shall be the ``unslept'' amount  (the  requested  time
62       minus the time actually slept) in seconds.
63

ERRORS

65       No errors are defined.
66
67       The following sections are informative.
68

EXAMPLES

70       None.
71

APPLICATION USAGE

73       None.
74

RATIONALE

76       There  are  two general approaches to the implementation of the sleep()
77       function. One is to use the alarm() function to schedule a SIGALRM sig‐
78       nal  and  then  suspend the calling thread waiting for that signal. The
79       other  is  to  implement  an  independent  facility.  This  volume   of
80       POSIX.1‐2017  permits  either approach in single-threaded programs, but
81       the simple alarm/suspend implementation is not appropriate  for  multi-
82       threaded programs.
83
84       In  order to comply with the requirement that no primitive shall change
85       a process attribute unless  explicitly  described  by  this  volume  of
86       POSIX.1‐2017,  an implementation using SIGALRM must carefully take into
87       account any SIGALRM signal scheduled by  previous  alarm()  calls,  the
88       action  previously  established  for  SIGALRM,  and whether SIGALRM was
89       blocked. If a SIGALRM has been scheduled before the sleep() would ordi‐
90       narily  complete,  the  sleep()  must  be  shortened to that time and a
91       SIGALRM generated (possibly simulated by direct invocation of the  sig‐
92       nal-catching  function)  before  sleep() returns. If a SIGALRM has been
93       scheduled after the sleep()  would  ordinarily  complete,  it  must  be
94       rescheduled  for  the  same time before sleep() returns. The action and
95       blocking for SIGALRM must be saved and restored.
96
97       Historical implementations often implement  the  SIGALRM-based  version
98       using  alarm()  and pause().  One such implementation is prone to infi‐
99       nite hangups, as described in  pause().   Another  such  implementation
100       uses the C-language setjmp() and longjmp() functions to avoid that win‐
101       dow. That implementation  introduces  a  different  problem:  when  the
102       SIGALRM  signal  interrupts a signal-catching function installed by the
103       user to catch a different signal, the  longjmp()  aborts  that  signal-
104       catching  function.  An implementation based on sigprocmask(), alarm(),
105       and sigsuspend() can avoid these problems.
106
107       Despite all  reasonable  care,  there  are  several  very  subtle,  but
108       detectable and unavoidable, differences between the two types of imple‐
109       mentations.  These  are  the  cases  mentioned  in   this   volume   of
110       POSIX.1‐2017 where some other activity relating to SIGALRM takes place,
111       and the results are stated to be unspecified. All of  these  cases  are
112       sufficiently unusual as not to be of concern to most applications.
113
114       See also the discussion of the term realtime in alarm().
115
116       Since  sleep()  can  be implemented using alarm(), the discussion about
117       alarms occurring early under alarm() applies to sleep() as well.
118
119       Application developers should note that the type of the  argument  sec‐
120       onds  and  the  return value of sleep() is unsigned.  That means that a
121       Strictly Conforming POSIX System Interfaces Application cannot  pass  a
122       value  greater  than the minimum guaranteed value for {UINT_MAX}, which
123       the ISO C standard sets as 65535, and any application passing a  larger
124       value  is restricting its portability. A different type was considered,
125       but historical implementations, including those with a 16-bit int type,
126       consistently use either unsigned or int.
127
128       Scheduling  delays  may  cause  the  process to return from the sleep()
129       function significantly after the requested time.  In  such  cases,  the
130       return  value  should be set to zero, since the formula (requested time
131       minus the time actually spent) yields a  negative  number  and  sleep()
132       returns an unsigned.
133

FUTURE DIRECTIONS

135       A  future  version  of  this standard may require that sleep() does not
136       make use of SIGALRM in all programs, not just multi-threaded programs.
137

SEE ALSO

139       alarm(), getitimer(), nanosleep(), pause(), sigaction(), sigsetjmp()
140
141       The Base Definitions volume of POSIX.1‐2017, <unistd.h>
142
144       Portions of this text are reprinted and reproduced in  electronic  form
145       from  IEEE Std 1003.1-2017, Standard for Information Technology -- Por‐
146       table Operating System Interface (POSIX), The Open Group Base  Specifi‐
147       cations  Issue  7, 2018 Edition, Copyright (C) 2018 by the Institute of
148       Electrical and Electronics Engineers, Inc and The Open Group.   In  the
149       event of any discrepancy between this version and the original IEEE and
150       The Open Group Standard, the original IEEE and The Open Group  Standard
151       is  the  referee document. The original Standard can be obtained online
152       at http://www.opengroup.org/unix/online.html .
153
154       Any typographical or formatting errors that appear  in  this  page  are
155       most likely to have been introduced during the conversion of the source
156       files to man page format. To report such errors,  see  https://www.ker
157       nel.org/doc/man-pages/reporting_bugs.html .
158
159
160
161IEEE/The Open Group                  2017                            SLEEP(3P)
Impressum