package async_kernel

  1. Overview
  2. Docs
Legend:
Library
Module
Module type
Parameter
Class
Class type

A synchronous version of Async_kernel.Time_source. advance_by_alarms runs alarms immediately, rather than enqueueing Async jobs.

Synchronous_time_source is a wrapper around Timing_wheel. One difference is that Synchronous_time_source alarms fire in non-decreasing time order, whereas in Timing_wheel that is only true for alarms in different time intervals as determined by alarm_precision.

module T1 : sig ... end
module Read_write : sig ... end
val sexp_of_t : t -> Ppx_sexp_conv_lib.Sexp.t
val invariant_with_jobs : job: (Async_kernel__.Types.Execution_context.t, Stdlib.Obj.t -> unit, Stdlib.Obj.t) Tuple_pool.Slots.t3 Tuple_pool.Pointer.t Core_kernel.Invariant.t -> t Core_kernel.Invariant.t
include Core_kernel.Invariant.S with type t := t
val invariant : t -> unit
val id : _ T1.t -> Id.t

id t returns a unique, consistent identifier which can be used e.g. as a map or hash table key.

val length : _ T1.t -> int

length t returns the number of alarms in the underlying Timing_wheel.

val read_only : [> Core_kernel.read ] T1.t -> t
type callback = unit -> unit
val create : ?timing_wheel_config:Timing_wheel.Config.t -> now:Core_kernel.Time_ns.t -> unit -> Core_kernel.read_write T1.t

create ~now () creates a new time source. The default timing_wheel_config has 100 microsecond precision, with levels of >1s, >1m, >1h, >1d. The timing_wheel_config is used to tune performance; configuration does not affect the fact that alarms fire in non-decreasing time order.

val is_wall_clock : [> Core_kernel.read ] T1.t -> bool

is_wall_clock reports whether this time source represents 'wall clock' time, or some alternate source of time.

The behavior of now is special for wall_clock (); it always calls Time_ns.now (), so it can return times that the time source has not yet been advanced to.

val timing_wheel_now : [> Core_kernel.read ] T1.t -> Core_kernel.Time_ns.t

Removes the special behavior of now for wall_clock (); it always returns the timing wheel's notion of now, which means that the following inequality always holds: timing_wheel_now () <= now ().

val advance_by_alarms : [> Core_kernel.write ] T1.t -> to_:Core_kernel.Time_ns.t -> unit Core_kernel.Or_error.t

advance_by_alarms t ~to_ advances t's time to to_, running callbacks for all alarms in t whose at <= to_. Callbacks run in nondecreasing order of at. If to_ <= now t, then now t does not change (and in particular does not go backward), but alarms with at <= to_ may still may fire.

val advance_directly : [> Core_kernel.write ] T1.t -> to_:Core_kernel.Time_ns.t -> unit Core_kernel.Or_error.t

Instead of advance_directly, you probably should use advance_by_alarms. advance_directly t ~to_ advances the clock directly to to_, whereas advance_by_alarms advances the clock in steps, to each intervening alarm. In particular periodic/rearming timers will fire at most twice.

val run_at : [> Core_kernel.read ] T1.t -> Core_kernel.Time_ns.t -> callback -> unit

run_at t at f schedules an alarm that will run f during the next subsequent advance_by_alarms t ~to_ that causes now t >= at. If at <= now t, then f will to run at the next call to advance_by_alarms. f is allowed to do all Synchronous_time_source operations except for advance_by_alarms (because f is already running during advance_by_alarms. Adding alarms is not zero-alloc and the underlying events live in the OCaml heap.

run_after t span f is run_at t (now t + span) f.

run_at_intervals t span f causes f to run at intervals now t + k * span, for k = 0, 1, 2, etc. run_at_intervals raises if span < alarm_precision t.

val max_allowed_alarm_time : [> Core_kernel.read ] T1.t -> Core_kernel.Time_ns.t

max_allowed_alarm_time t returns the greatest at that can be supplied to add. max_allowed_alarm_time is not constant; its value increases as now t increases.

module Event : sig ... end
val default_timing_wheel_config : Timing_wheel.Config.t
val wall_clock : unit -> t

A time source with now t given by wall-clock time (i.e. Time_ns.now), and automatically advanced at the start of each Async cycle. The wall clock uses the same timing wheel as that used by the Async scheduler, and is hence similarly affected by the ASYNC_CONFIG environment variable.

OCaml

Innovation. Community. Security.