ALARM man page on Archlinux

Man page or keyword search:  
man Server   11224 pages
apropos Keyword Search (all sections)
Output format
Archlinux logo
[printable version]

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

       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.

       alarm — schedule an alarm signal

       #include <unistd.h>

       unsigned alarm(unsigned seconds);

       The alarm() function shall cause the system to generate a SIGALRM  sig‐
       nal  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 generated.

       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 gener‐
       ated,  the  call	 shall	result	in  rescheduling the time at which the
       SIGALRM signal is generated.

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

       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.

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

       The following sections are informative.


       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  sec‐
       onds  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() functions.

       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 appro‐
       priate, 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-spe‐
       cific maximum value. This maximum is large enough (to the order of sev‐
       eral 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 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 justified.


       alarm(), exec, fork(), getitimer(), pause(), sigaction(), sleep()

       The Base Definitions volume of POSIX.1‐2008, <signal.h>, <unistd.h>

       Portions of this text are reprinted and reproduced in  electronic  form
       from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
       -- Portable Operating System Interface (POSIX),	The  Open  Group  Base
       Specifications Issue 7, Copyright (C) 2013 by the Institute of Electri‐
       cal and Electronics Engineers,  Inc  and	 The  Open  Group.   (This  is
       POSIX.1-2008  with  the	2013  Technical Corrigendum 1 applied.) 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 https://www.ker‐ .

IEEE/The Open Group		     2013			     ALARM(3P)

List of man pages available for Archlinux

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net