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

timer_create.3p (10020B)


  1. '\" et
  2. .TH TIMER_CREATE "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. timer_create
  12. \(em create a per-process timer
  13. .SH SYNOPSIS
  14. .LP
  15. .nf
  16. #include <signal.h>
  17. #include <time.h>
  18. .P
  19. int timer_create(clockid_t \fIclockid\fP, struct sigevent *restrict \fIevp\fP,
  20. timer_t *restrict \fItimerid\fP);
  21. .fi
  22. .SH DESCRIPTION
  23. The
  24. \fItimer_create\fR()
  25. function shall create a per-process timer using the specified clock,
  26. .IR clock_id ,
  27. as the timing base. The
  28. \fItimer_create\fR()
  29. function shall return, in the location referenced by
  30. .IR timerid ,
  31. a timer ID of type
  32. .BR timer_t
  33. used to identify the timer in timer requests. This timer ID shall be
  34. unique within the calling process until the timer is deleted. The
  35. particular clock,
  36. .IR clock_id ,
  37. is defined in
  38. .IR <time.h> .
  39. The timer whose ID is returned shall be in a disarmed state upon return
  40. from
  41. \fItimer_create\fR().
  42. .P
  43. The
  44. .IR evp
  45. argument, if non-NULL, points to a
  46. .BR sigevent
  47. structure. This structure, allocated by the application, defines the
  48. asynchronous notification to occur as specified in
  49. .IR "Section 2.4.1" ", " "Signal Generation and Delivery"
  50. when the timer expires. If the
  51. .IR evp
  52. argument is NULL, the effect is as if the
  53. .IR evp
  54. argument pointed to a
  55. .BR sigevent
  56. structure with the
  57. .IR sigev_notify
  58. member having the value SIGEV_SIGNAL, the
  59. .IR sigev_signo
  60. having a default signal number, and the
  61. .IR sigev_value
  62. member having the value of the timer ID.
  63. .P
  64. Each implementation shall define a set of clocks that can be used as
  65. timing bases for per-process timers. All implementations shall support a
  66. .IR clock_id
  67. of CLOCK_REALTIME.
  68. If the Monotonic Clock option is supported, implementations shall
  69. support a
  70. .IR clock_id
  71. of CLOCK_MONOTONIC.
  72. .P
  73. Per-process timers shall not be inherited by a child process across a
  74. \fIfork\fR()
  75. and shall be disarmed and deleted by an
  76. .IR exec .
  77. .P
  78. If _POSIX_CPUTIME is defined, implementations shall support
  79. .IR clock_id
  80. values representing the CPU-time clock of the calling process.
  81. .P
  82. If _POSIX_THREAD_CPUTIME is defined, implementations shall support
  83. .IR clock_id
  84. values representing the CPU-time clock of the calling thread.
  85. .P
  86. It is implementation-defined whether a
  87. \fItimer_create\fR()
  88. function will succeed if the value defined by
  89. .IR clock_id
  90. corresponds to the CPU-time clock of a process or thread different from
  91. the process or thread invoking the function.
  92. .P
  93. If \fIevp\fR\->\fIsigev_sigev_notify\fR is SIGEV_THREAD and
  94. \fIsev\fR\->\fIsigev_notify_attributes\fR is not NULL, if the attribute
  95. pointed to by \fIsev\fR\->\fIsigev_notify_attributes\fR has a thread
  96. stack address specified by a call to
  97. \fIpthread_attr_setstack\fR(),
  98. the results are unspecified if the signal is generated more than once.
  99. .SH "RETURN VALUE"
  100. If the call succeeds,
  101. \fItimer_create\fR()
  102. shall return zero and update the location referenced by
  103. .IR timerid
  104. to a
  105. .BR timer_t ,
  106. which can be passed to the per-process timer calls. If an error
  107. occurs, the function shall return a value of \-1 and set
  108. .IR errno
  109. to indicate the error. The value of
  110. .IR timerid
  111. is undefined if an error occurs.
  112. .SH ERRORS
  113. The
  114. \fItimer_create\fR()
  115. function shall fail if:
  116. .TP
  117. .BR EAGAIN
  118. The system lacks sufficient signal queuing resources to honor the
  119. request.
  120. .TP
  121. .BR EAGAIN
  122. The calling process has already created all of the timers it is allowed
  123. by this implementation.
  124. .TP
  125. .BR EINVAL
  126. The specified clock ID is not defined.
  127. .TP
  128. .BR ENOTSUP
  129. The implementation does not support the creation of a timer attached to
  130. the CPU-time clock that is specified by
  131. .IR clock_id
  132. and associated with a process or thread different from the process or
  133. thread invoking
  134. \fItimer_create\fR().
  135. .LP
  136. .IR "The following sections are informative."
  137. .SH EXAMPLES
  138. None.
  139. .SH "APPLICATION USAGE"
  140. If a timer is created which has \fIevp\fR\->\fIsigev_sigev_notify\fR
  141. set to SIGEV_THREAD and the attribute pointed to by
  142. \fIevp\fR\->\fIsigev_notify_attributes\fR has a thread stack address
  143. specified by a call to
  144. \fIpthread_attr_setstack\fR(),
  145. the memory dedicated as a thread stack cannot be recovered. The reason
  146. for this is that the threads created in response to a timer expiration
  147. are created detached, or in an unspecified way if the thread
  148. attribute's
  149. .IR detachstate
  150. is PTHREAD_CREATE_JOINABLE. In neither case is it valid to call
  151. \fIpthread_join\fR(),
  152. which makes it impossible to determine the lifetime of the created
  153. thread which thus means the stack memory cannot be reused.
  154. .br
  155. .SH RATIONALE
  156. .SS "Periodic Timer Overrun and Resource Allocation"
  157. .P
  158. The specified timer facilities may deliver realtime signals (that is,
  159. queued signals) on implementations that support this option. Since
  160. realtime applications cannot afford to lose notifications of
  161. asynchronous events, like timer expirations or asynchronous I/O
  162. completions, it must be possible to ensure that sufficient resources
  163. exist to deliver the signal when the event occurs. In general, this is
  164. not a difficulty because there is a one-to-one correspondence between a
  165. request and a subsequent signal generation. If the request cannot
  166. allocate the signal delivery resources, it can fail the call with an
  167. .BR [EAGAIN]
  168. error.
  169. .P
  170. Periodic timers are a special case. A single request can generate an
  171. unspecified number of signals. This is not a problem if the
  172. requesting process can service the signals as fast as they are
  173. generated, thus making the signal delivery resources available for
  174. delivery of subsequent periodic timer expiration signals. But, in
  175. general, this cannot be assured\(emprocessing of periodic timer signals
  176. may ``overrun''; that is, subsequent periodic timer expirations may
  177. occur before the currently pending signal has been delivered.
  178. .P
  179. Also, for signals, according to the POSIX.1\(hy1990 standard, if subsequent occurrences of
  180. a pending signal are generated, it is implementation-defined whether
  181. a signal is delivered for each occurrence. This is not adequate for
  182. some realtime applications. So a mechanism is required to allow
  183. applications to detect how many timer expirations were delayed without
  184. requiring an indefinite amount of system resources to store the delayed
  185. expirations.
  186. .P
  187. The specified facilities provide for an overrun count. The overrun
  188. count is defined as the number of extra timer expirations that occurred
  189. between the time a timer expiration signal is generated and the time
  190. the signal is delivered. The signal-catching function, if it is
  191. concerned with overruns, can retrieve this count on entry. With this
  192. method, a periodic timer only needs one ``signal queuing resource''
  193. that can be allocated at the time of the
  194. \fItimer_create\fR()
  195. function call.
  196. .P
  197. A function is defined to retrieve the overrun count so that an
  198. application need not allocate static storage to contain the count, and
  199. an implementation need not update this storage asynchronously on timer
  200. expirations. But, for some high-frequency periodic applications, the
  201. overhead of an additional system call on each timer expiration may be
  202. prohibitive. The functions, as defined, permit an implementation to
  203. maintain the overrun count in user space, associated with the
  204. .IR timerid .
  205. The
  206. \fItimer_getoverrun\fR()
  207. function can then be implemented as a macro that uses the
  208. .IR timerid
  209. argument (which may just be a pointer to a user space structure
  210. containing the counter) to locate the overrun count with no system call
  211. overhead. Other implementations, less concerned with this class of
  212. applications, can avoid the asynchronous update of user space by
  213. maintaining the count in a system structure at the cost of the extra
  214. system call to obtain it.
  215. .SS "Timer Expiration Signal Parameters"
  216. .P
  217. The Realtime Signals Extension option supports an application-specific
  218. datum that is delivered to the extended signal handler. This value is
  219. explicitly specified by the application, along with the signal number
  220. to be delivered, in a
  221. .BR sigevent
  222. structure. The type of the application-defined value can be either an
  223. integer constant or a pointer. This explicit specification of the
  224. value, as opposed to always sending the
  225. timer ID, was selected based on existing practice.
  226. .P
  227. It is common practice for realtime applications (on non-POSIX systems
  228. or realtime extended POSIX systems) to use the parameters of event
  229. handlers as the case label of a switch statement or as a pointer to an
  230. application-defined data structure. Since
  231. .IR timer_id s
  232. are dynamically allocated by the
  233. \fItimer_create\fR()
  234. function, they can be used for neither of these functions without
  235. additional application overhead in the signal handler; for example, to
  236. search an array of saved timer IDs to associate the ID with a constant
  237. or application data structure.
  238. .SH "FUTURE DIRECTIONS"
  239. None.
  240. .SH "SEE ALSO"
  241. .IR "\fIclock_getres\fR\^(\|)",
  242. .IR "\fItimer_delete\fR\^(\|)",
  243. .IR "\fItimer_getoverrun\fR\^(\|)"
  244. .P
  245. The Base Definitions volume of POSIX.1\(hy2017,
  246. .IR "\fB<signal.h>\fP",
  247. .IR "\fB<time.h>\fP"
  248. .\"
  249. .SH COPYRIGHT
  250. Portions of this text are reprinted and reproduced in electronic form
  251. from IEEE Std 1003.1-2017, Standard for Information Technology
  252. -- Portable Operating System Interface (POSIX), The Open Group Base
  253. Specifications Issue 7, 2018 Edition,
  254. Copyright (C) 2018 by the Institute of
  255. Electrical and Electronics Engineers, Inc and The Open Group.
  256. In the event of any discrepancy between this version and the original IEEE and
  257. The Open Group Standard, the original IEEE and The Open Group Standard
  258. is the referee document. The original Standard can be obtained online at
  259. http://www.opengroup.org/unix/online.html .
  260. .PP
  261. Any typographical or formatting errors that appear
  262. in this page are most likely
  263. to have been introduced during the conversion of the source files to
  264. man page format. To report such errors, see
  265. https://www.kernel.org/doc/man-pages/reporting_bugs.html .