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



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

NNAAMMEE
       alarm -- schedule an alarm signal

SSYYNNOOPPSSIISS
       #include <unistd.h>

       unsigned alarm(unsigned _s_e_c_o_n_d_s);

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

       If _s_e_c_o_n_d_s 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 _a_l_a_r_m() and _s_e_t_i_t_i_m_e_r() are unspecified.

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

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

       _T_h_e _f_o_l_l_o_w_i_n_g _s_e_c_t_i_o_n_s _a_r_e _i_n_f_o_r_m_a_t_i_v_e_.

EEXXAAMMPPLLEESS
       None.

AAPPPPLLIICCAATTIIOONN UUSSAAGGEE
       The _f_o_r_k() function clears pending alarms in the child process. A new
       process image created by one of the _e_x_e_c 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
       _s_e_c_o_n_d_s and the return value of _a_l_a_r_m() is uunnssiiggnneedd.  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 iinntt type,
       consistently use either uunnssiiggnneedd or iinntt.

       Application developers should be aware of possible interactions when
       the same process uses both the _a_l_a_r_m() and _s_l_e_e_p() functions.

RRAATTIIOONNAALLEE
       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 _s_e_c_o_n_d_s argument as
       the minimum amount of time they wish to have elapse before the signal.

       The term ``realtime'' here and elsewhere (_s_l_e_e_p(), _t_i_m_e_s()) 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 _v_i_r_t_u_a_l
       _t_i_m_e, which could be misinterpreted if just _t_i_m_e were used.

       In some implementations, including 4.3 BSD, very large values of the
       _s_e_c_o_n_d_s 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 noticeable.

       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 _a_l_a_r_m() 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 justified.

FFUUTTUURREE DDIIRREECCTTIIOONNSS
       None.

SSEEEE AALLSSOO
       _a_l_a_r_m(), _e_x_e_c, _f_o_r_k(), _g_e_t_i_t_i_m_e_r(), _p_a_u_s_e(), _s_i_g_a_c_t_i_o_n(), _s_l_e_e_p()

       The Base Definitions volume of POSIX.1-2017, <<ssiiggnnaall..hh>>, <<uunniissttdd..hh>>

CCOOPPYYRRIIGGHHTT
       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 http://www.opengroup.org/unix/online.html .

       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
       https://www.kernel.org/doc/man-pages/reporting_bugs.html .



IEEE/The Open Group                  2017                             ALARM(3)
