NAME | FEATURE SUMMARY | API | ATTRIBUTES
The TIMER feature implements a high-level timer service for both user and supervisor actors. One-shot and periodic timers are provided, with timeout notification by execution of a user-provided upcall function by a handler thread in the application actor. Handler threads may invoke any kernel or subsystem system call. This service is implemented using the TIMEOUT feature.
The extended timer facility uses the concept of a timer object within the actor environment. Timers are created and deleted dynamically. Once created, they are addressed by a local identifier in the context of their owning actor, and are deleted automatically when that actor terminates. Timer objects provide a naming mechanism and a locus of control for timing activities. All high-level timer operations, for example, setting, modifying, querying, or cancelling pending timeouts, refer to timer objects. Timer objects are also involved in coordination with the threads used to execute application-level notification handlers.
Applications will typically use extended timer functions via a standard application-level library (see the POSIX-TIMERS feature). Timer handler threads are created and managed by this library. The library is expected to pre-allocate stack area for the notification functions, create the thread, and initialize the thread's priority, per-thread data, and all other aspects of its execution context, using standard system calls. The thread then declares itself available for execution of the timer notification (timerThreadPoolWait) system call to wait for the first or next relevant timeout event. Event arrival will cause the thread to return from the system call, at which point the library code can call the application's handler. The ``thread pool'' interface is designed to allow one or a small number of handler threads to service an arbitrary number of timers. An application can thus create a large number of handlers without the expense of a dedicated handler thread for each one.
At most, a single notification will be active for a given timer at any point in time. If no handler thread is available when the timer interval expires, either because the notification function is still executing from a previous expiration or because the handler thread(s) is (are) occupied executing notifications for other timers, an overrun occurs. When a handler thread becomes available (that is, re-executes timerThreadPoolWait), it will return immediately and the notification function may be invoked immediately. At return from timerThreadPoolWait, an overrun count is delivered to the thread. An overrun count value pertains to a particular execution of the notification function. The overrun count is defined as the number of timer expirations that occurred since the previous invocation of the notify function without a handler thread available. Thus for a periodic timer, an overrun count equal to one indicates that the current invocation was delayed, but by less than the period interval.
The TIMER API is summarized in the following table:
Comment
Initialize a thread pool
Wait for timer events
Create a timer
Delete a timer
Get timer resolution
Set a timer
See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPE | ATTRIBUTE VALUE |
---|---|
Interface Stability | Evolving |
NAME | FEATURE SUMMARY | API | ATTRIBUTES