1ALARM(3P)                  POSIX Programmer's Manual                 ALARM(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       alarm — schedule an alarm signal
13

SYNOPSIS

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

DESCRIPTION

20       The alarm() function shall cause the system to generate a SIGALRM  sig‐
21       nal  for  the process after the number of realtime seconds specified by
22       seconds have elapsed.  Processor  scheduling  delays  may  prevent  the
23       process from handling the signal as soon as it is generated.
24
25       If seconds is 0, a pending alarm request, if any, is canceled.
26
27       Alarm  requests  are  not  stacked;  only one SIGALRM generation can be
28       scheduled in this manner. If the SIGALRM signal has not yet been gener‐
29       ated,  the  call  shall  result  in  rescheduling the time at which the
30       SIGALRM signal is generated.
31
32       Interactions between alarm() and setitimer() are unspecified.
33

RETURN VALUE

35       If there is a previous alarm() request  with  time  remaining,  alarm()
36       shall  return  a non-zero value that is the number of seconds until the
37       previous request would have  generated  a  SIGALRM  signal.  Otherwise,
38       alarm() shall return 0.
39

ERRORS

41       The  alarm()  function  is  always  successful,  and no return value is
42       reserved to indicate an error.
43
44       The following sections are informative.
45

EXAMPLES

47       None.
48

APPLICATION USAGE

50       The fork() function clears pending alarms in the child process.  A  new
51       process  image  created  by one of the exec functions inherits the time
52       left to an alarm signal in the image of the old process.
53
54       Application developers should note that the type of the  argument  sec‐
55       onds  and  the  return value of alarm() is unsigned.  That means that a
56       Strictly Conforming POSIX System Interfaces Application cannot  pass  a
57       value  greater  than the minimum guaranteed value for {UINT_MAX}, which
58       the ISO C standard sets as 65535, and any application passing a  larger
59       value  is restricting its portability. A different type was considered,
60       but historical implementations, including those with a 16-bit int type,
61       consistently use either unsigned or int.
62
63       Application  developers  should  be aware of possible interactions when
64       the same process uses both the alarm() and sleep() functions.
65

RATIONALE

67       Many historical implementations (including  Version  7  and  System  V)
68       allow  an  alarm  to occur up to a second early.  Other implementations
69       allow alarms up to half a second or one clock  tick  early  or  do  not
70       allow  them to occur early at all. The latter is considered most appro‐
71       priate, since it gives the most predictable behavior, especially  since
72       the  signal  can always be delayed for an indefinite amount of time due
73       to scheduling. Applications can thus choose the seconds argument as the
74       minimum amount of time they wish to have elapse before the signal.
75
76       The term ``realtime'' here and elsewhere (sleep(), times()) is intended
77       to mean ``wall clock'' time as common English usage, and has nothing to
78       do  with  ``realtime  operating systems''. It is in contrast to virtual
79       time, which could be misinterpreted if just time were used.
80
81       In some implementations, including 4.3 BSD, very large  values  of  the
82       seconds  argument  are  silently rounded down to an implementation-spe‐
83       cific maximum value. This maximum is large enough (to the order of sev‐
84       eral months) that the effect is not noticeable.
85
86       There  were two possible choices for alarm generation in multi-threaded
87       applications: generation for the calling thread or generation  for  the
88       process. The first option would not have been particularly useful since
89       the alarm state is maintained on a per-process basis and the alarm that
90       is  established  by the last invocation of alarm() is the only one that
91       would be active.
92
93       Furthermore, allowing generation of an asynchronous signal for a thread
94       would  have  introduced  an exception to the overall signal model. This
95       requires a compelling reason in order to be justified.
96

FUTURE DIRECTIONS

98       None.
99

SEE ALSO

101       alarm(), exec, fork(), getitimer(), pause(), sigaction(), sleep()
102
103       The Base Definitions volume of POSIX.1‐2017, <signal.h>, <unistd.h>
104
106       Portions of this text are reprinted and reproduced in  electronic  form
107       from  IEEE Std 1003.1-2017, Standard for Information Technology -- Por‐
108       table Operating System Interface (POSIX), The Open Group Base  Specifi‐
109       cations  Issue  7, 2018 Edition, Copyright (C) 2018 by the Institute of
110       Electrical and Electronics Engineers, Inc and The Open Group.   In  the
111       event of any discrepancy between this version and the original IEEE and
112       The Open Group Standard, the original IEEE and The Open Group  Standard
113       is  the  referee document. The original Standard can be obtained online
114       at http://www.opengroup.org/unix/online.html .
115
116       Any typographical or formatting errors that appear  in  this  page  are
117       most likely to have been introduced during the conversion of the source
118       files to man page format. To report such errors,  see  https://www.ker
119       nel.org/doc/man-pages/reporting_bugs.html .
120
121
122
123IEEE/The Open Group                  2017                            ALARM(3P)
Impressum