logo

oasis-root

Compiled tree of Oasis Linux based on own branch at <https://hacktivis.me/git/oasis/> git clone https://anongit.hacktivis.me/git/oasis-root.git

alarm.3p (5446B)


  1. '\" et
  2. .TH ALARM "3P" 2017 "IEEE/The Open Group" "POSIX Programmer's Manual"
  3. .\"
  4. .SH PROLOG
  5. This manual page is part of the POSIX Programmer's Manual.
  6. The Linux implementation of this interface may differ (consult
  7. the corresponding Linux manual page for details of Linux behavior),
  8. or the interface may not be implemented on Linux.
  9. .\"
  10. .SH NAME
  11. alarm
  12. \(em schedule an alarm signal
  13. .SH SYNOPSIS
  14. .LP
  15. .nf
  16. #include <unistd.h>
  17. .P
  18. unsigned alarm(unsigned \fIseconds\fP);
  19. .fi
  20. .SH DESCRIPTION
  21. The
  22. \fIalarm\fR()
  23. function shall cause the system to generate a SIGALRM signal for the
  24. process after the number of realtime seconds specified by
  25. .IR seconds
  26. have elapsed. Processor scheduling delays may prevent the process from
  27. handling the signal as soon as it is generated.
  28. .P
  29. If
  30. .IR seconds
  31. is 0, a pending alarm request, if any, is canceled.
  32. .P
  33. Alarm requests are not stacked; only one SIGALRM generation can be
  34. scheduled in this manner. If the SIGALRM signal has not yet been
  35. generated, the call shall result in rescheduling the time at which the
  36. SIGALRM signal is generated.
  37. .P
  38. Interactions between
  39. \fIalarm\fR()
  40. and
  41. \fIsetitimer\fR()
  42. are unspecified.
  43. .SH "RETURN VALUE"
  44. If there is a previous
  45. \fIalarm\fR()
  46. request with time remaining,
  47. \fIalarm\fR()
  48. shall return a non-zero value that is the number of seconds until the
  49. previous request would have generated a SIGALRM signal. Otherwise,
  50. \fIalarm\fR()
  51. shall return 0.
  52. .SH ERRORS
  53. The
  54. \fIalarm\fR()
  55. function is always successful, and no return value is reserved to
  56. indicate an error.
  57. .LP
  58. .IR "The following sections are informative."
  59. .SH EXAMPLES
  60. None.
  61. .SH "APPLICATION USAGE"
  62. The
  63. \fIfork\fR()
  64. function clears pending alarms in the child process. A new process
  65. image created by one of the
  66. .IR exec
  67. functions inherits the time left to an alarm signal in the
  68. image of the old process.
  69. .P
  70. Application developers should note that the type of the argument
  71. .IR seconds
  72. and the return value of
  73. \fIalarm\fR()
  74. is
  75. .BR unsigned .
  76. That means that a Strictly Conforming POSIX System Interfaces
  77. Application cannot pass a value greater than the minimum guaranteed
  78. value for
  79. {UINT_MAX},
  80. which the ISO\ C standard
  81. sets as 65\|535, and any application passing a larger value is
  82. restricting its portability. A different type was considered, but
  83. historical implementations, including those with a 16-bit
  84. .BR int
  85. type, consistently use either
  86. .BR unsigned
  87. or
  88. .BR int .
  89. .P
  90. Application developers should be aware of possible interactions when
  91. the same process uses both the
  92. \fIalarm\fR()
  93. and
  94. \fIsleep\fR()
  95. functions.
  96. .SH RATIONALE
  97. Many historical implementations (including Version 7
  98. and System V) allow an alarm to occur up to a second early.
  99. Other implementations allow alarms up to half a second or one clock
  100. tick early or do not
  101. allow them to occur early at all. The latter is considered most
  102. appropriate, since it gives the most predictable behavior, especially
  103. since the signal can always be delayed for an indefinite amount of time
  104. due to scheduling. Applications can thus choose the
  105. .IR seconds
  106. argument as the minimum amount of time they wish to have elapse before
  107. the signal.
  108. .P
  109. The term ``realtime'' here and elsewhere (\c
  110. \fIsleep\fR(),
  111. \fItimes\fR())
  112. is intended to mean ``wall clock'' time as common English usage, and
  113. has nothing to do with ``realtime operating systems''. It is in
  114. contrast to \fIvirtual time\fP, which could be misinterpreted if just
  115. \fItime\fP were used.
  116. .P
  117. In some implementations, including 4.3 BSD, very large values of the
  118. .IR seconds
  119. argument are silently rounded down to an implementation-specific maximum
  120. value. This maximum is large enough (to the order of several months)
  121. that the effect is not noticeable.
  122. .P
  123. There were two possible choices for alarm generation in multi-threaded
  124. applications: generation for the calling thread or generation for the
  125. process. The first option would not have been particularly useful
  126. since the alarm state is maintained on a per-process basis and the
  127. alarm that is established by the last invocation of
  128. \fIalarm\fR()
  129. is the only one that would be active.
  130. .P
  131. Furthermore, allowing generation of an asynchronous signal for a thread
  132. would have introduced an exception to the overall signal model. This
  133. requires a compelling reason in order to be justified.
  134. .SH "FUTURE DIRECTIONS"
  135. None.
  136. .SH "SEE ALSO"
  137. .IR "\fIalarm\fR\^(\|)",
  138. .IR "\fIexec\fR\^",
  139. .IR "\fIfork\fR\^(\|)",
  140. .IR "\fIgetitimer\fR\^(\|)",
  141. .IR "\fIpause\fR\^(\|)",
  142. .IR "\fIsigaction\fR\^(\|)",
  143. .IR "\fIsleep\fR\^(\|)"
  144. .P
  145. The Base Definitions volume of POSIX.1\(hy2017,
  146. .IR "\fB<signal.h>\fP",
  147. .IR "\fB<unistd.h>\fP"
  148. .\"
  149. .SH COPYRIGHT
  150. Portions of this text are reprinted and reproduced in electronic form
  151. from IEEE Std 1003.1-2017, Standard for Information Technology
  152. -- Portable Operating System Interface (POSIX), The Open Group Base
  153. Specifications Issue 7, 2018 Edition,
  154. Copyright (C) 2018 by the Institute of
  155. Electrical and Electronics Engineers, Inc and The Open Group.
  156. In the event of any discrepancy between this version and the original IEEE and
  157. The Open Group Standard, the original IEEE and The Open Group Standard
  158. is the referee document. The original Standard can be obtained online at
  159. http://www.opengroup.org/unix/online.html .
  160. .PP
  161. Any typographical or formatting errors that appear
  162. in this page are most likely
  163. to have been introduced during the conversion of the source files to
  164. man page format. To report such errors, see
  165. https://www.kernel.org/doc/man-pages/reporting_bugs.html .