alarm(3p) — Linux manual page


ALARM(3P)               POSIX Programmer's Manual              ALARM(3P)

PROLOG         top

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

NAME         top

       alarm — schedule an alarm signal

SYNOPSIS         top

       #include <unistd.h>

       unsigned alarm(unsigned seconds);

DESCRIPTION         top

       The alarm() function shall cause the system to generate a SIGALRM
       signal for the process after the number of realtime seconds
       specified by seconds have elapsed. Processor scheduling delays
       may prevent the process from handling the signal as soon as it is

       If seconds is 0, a pending alarm request, if any, is canceled.

       Alarm requests are not stacked; only one SIGALRM generation can
       be scheduled in this manner. If the SIGALRM signal has not yet
       been generated, the call shall result in rescheduling the time at
       which the SIGALRM signal is generated.

       Interactions between alarm() and setitimer() are unspecified.

RETURN VALUE         top

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

ERRORS         top

       The alarm() function is always successful, and no return value is
       reserved to indicate an error.

       The following sections are informative.

EXAMPLES         top



       The fork() function clears pending alarms in the child process. A
       new process image created by one of the exec functions inherits
       the time left to an alarm signal in the image of the old process.

       Application developers should note that the type of the argument
       seconds and the return value of alarm() is unsigned.  That means
       that a Strictly Conforming POSIX System Interfaces Application
       cannot pass a value greater than the minimum guaranteed value for
       {UINT_MAX}, which the ISO C standard sets as 65535, and any
       application passing a larger value is restricting its
       portability. A different type was considered, but historical
       implementations, including those with a 16-bit int type,
       consistently use either unsigned or int.

       Application developers should be aware of possible interactions
       when the same process uses both the alarm() and sleep()

RATIONALE         top

       Many historical implementations (including Version 7 and System
       V) allow an alarm to occur up to a second early.  Other
       implementations allow alarms up to half a second or one clock
       tick early or do not allow them to occur early at all. The latter
       is considered most appropriate, since it gives the most
       predictable behavior, especially since the signal can always be
       delayed for an indefinite amount of time due to scheduling.
       Applications can thus choose the seconds argument as the minimum
       amount of time they wish to have elapse before the signal.

       The term ``realtime'' here and elsewhere (sleep(), times()) is
       intended to mean ``wall clock'' time as common English usage, and
       has nothing to do with ``realtime operating systems''. It is in
       contrast to virtual time, which could be misinterpreted if just
       time were used.

       In some implementations, including 4.3 BSD, very large values of
       the seconds argument are silently rounded down to an
       implementation-specific maximum value. This maximum is large
       enough (to the order of several months) that the effect is not

       There were two possible choices for alarm generation in multi-
       threaded applications: generation for the calling thread or
       generation for the process. The first option would not have been
       particularly useful since the alarm state is maintained on a per-
       process basis and the alarm that is established by the last
       invocation of alarm() is the only one that would be active.

       Furthermore, allowing generation of an asynchronous signal for a
       thread would have introduced an exception to the overall signal
       model. This requires a compelling reason in order to be



SEE ALSO         top

       alarm(3p), exec(1p), fork(3p), getitimer(3p), pause(3p),
       sigaction(3p), sleep(3p)

       The Base Definitions volume of POSIX.1‐2017, signal.h(0p),

COPYRIGHT         top

       Portions of this text are reprinted and reproduced in electronic
       form from IEEE Std 1003.1-2017, Standard for Information
       Technology -- Portable Operating System Interface (POSIX), The
       Open Group Base Specifications Issue 7, 2018 Edition, Copyright
       (C) 2018 by the Institute of Electrical and Electronics
       Engineers, Inc and The Open Group.  In the event of any
       discrepancy between this version and the original IEEE and The
       Open Group Standard, the original IEEE and The Open Group
       Standard is the referee document. The original Standard can be
       obtained online at .

       Any typographical or formatting errors that appear in this page
       are most likely to have been introduced during the conversion of
       the source files to man page format. To report such errors, see .

IEEE/The Open Group               2017                         ALARM(3P)

Pages that refer to this page: signal.h(0p)unistd.h(0p)sleep(1p)alarm(3p)exec(3p)fcntl(3p)fork(3p)getitimer(3p)lockf(3p)posix_spawn(3p)pselect(3p)sleep(3p)times(3p)