NAME    [Toc]    [Back]

     callout_init, callout_reset, callout_stop - execute a function after a
     specified length of time

SYNOPSIS    [Toc]    [Back]

     #include <sys/callout.h>

     void
     callout_init(struct callout *c);

     void
     callout_reset(struct callout *c, int ticks, void (*func)(void *),
             void *arg);

     void
     callout_stop(struct callout *c);

     int
     callout_active(struct callout *c);

     int
     callout_pending(struct callout *c);

     int
     callout_expired(struct callout *c);

     void
     callout_deactivate(struct callout *c);

     int
     callout_invoking(struct callout *c);

     void
     callout_ack(struct callout *c);

DESCRIPTION    [Toc]    [Back]

     The callout facility provides a mechanism to execute a function at a
     given time.  The timer is based on the hardclock timer which ticks hz
     times per second.  The function is called at softclock interrupt level.

     Clients of the callout facility are responsible for providing pre-allocated
 callout structures, or ``handles''.  The callout facility replaces
     the historic BSD functions timeout() and untimeout().

     The callout_init() function initializes the callout handle c for use.  If
     it is inconvenient to call callout_init(), statically-allocated callout
     handles may be initialized by assigning the value CALLOUT_INITIALIZER to
     them.

     The callout_reset() function starts (or resets) the timer associated with
     the callout handle c.  When the timer expires after ticks/hz seconds, the
     function specified by func will be called with the argument arg.  Note
     that if the timer associated with the callout handle is already running,
     it will be implicitly stopped before being reset.  Once the timer is
     started, the callout handle is marked as ACTIVE and PENDING.  Once the
     timer expires, PENDING status is cleared.  Expiration of the timer does
     not affect ACTIVE status.

     The callout_stop() function stops the timer associated the callout handle
     c.  The ACTIVE and PENDING status for the callout handle is cleared.  It
     is safe to call callout_stop() on a callout handle that is not active, so
     long as it is initialized.

     The callout_active() function tests the ACTIVE status of the callout handle
 c.  An ACTIVE callout is one that has been started but not explicitly
     stopped.  Testing ACTIVE status is a way to determine if a callout has
     been started.  Once the callout fires, the executed function may clear
     ACTIVE status.  See callout_deactivate() below.

     The callout_pending() function tests the PENDING status of the callout
     handle c.  A PENDING callout is one that has been started and whose function
 has not yet been called.  Note that it is possible for a callout's
     timer to have expired without its function being called if interrupt
     level has not dropped low enough to let softclock interrupts through.
     Note that it is only safe to test PENDING status when at softclock interrupt
 level or higher.

     The callout_expired() function tests the opposite of callout_pending().
     That is to say that callout_expired() returns true when the callout function
 has been called.

     The callout_deactivate() function clears the ACTIVE status of the callout
     handle c.  Note that is only safe to call callout_deactivate() if the
     callout function has already been executed, i.e. the callout is no longer
     PENDING.

     The callout_invoking() function checks whether the callout function in
     the callout handle c is about to be executed, at which time the INVOKING
     status is set.  Since the priority is lowered prior to invocation of the
     callout function, other pending higher-priority code may run before the
     callout function is actually invoked.  This may create a race condition
     if this higher-priority code deallocates storage containing one or more
     callout structures whose callout functions are about to run.  In such
     cases one technique to prevent references to deallocated storage would be
     to test whether any callout functions are in the INVOKING state using
     callout_invoking(), and if so, to mark the data structure and defer storage
 deallocation until the callout function is allowed to run.  For this
     handshake protocol to work, the callout function will have to use the
     callout_ack() function to clear this flag.

     The callout_ack() function clears the INVOKING state in the callout handle
 c.  This is used in situations where it is necessary to protect
     against the race condition described under callout_invoking().

SEE ALSO    [Toc]    [Back]

     hz(9)

HISTORY    [Toc]    [Back]

     The callout facility is based on the work of Adam M. Costello and George
     Varghese, published in a technical report entitled ``Redesigning the BSD
     Callout and Timer Facilities'', and Justin Gibbs's subsequent integration
     into FreeBSD.  It was modified for NetBSD by Jason R. Thorpe, who also
     added optional statistics gathering and an alternate sorting mode for the
     callwheel.

     The original work on the data structures used in this implementation was
     published by G. Varghese and A. Lauck in the paper Hashed and Hierarchical
 Timing Wheels: Data Structures for the Efficient Implementation of a
     Timer Facility in the Proceedings of the 11th ACM Annual Symposium on
     Operating System Principles, Austin, Texas, November 1987.

BSD                             March 21, 2000                             BSD