run_at time f a runs f a as soon as possible after time. If time is in the past, then run_at will immediately schedule a job t that will run f a. In no situation will run_at actually call f itself. The call to f will always be in another job.

run_after is like run_at, except that one specifies a time span rather than an absolute time.

at time returns a deferred d that will become determined as soon as possible after time.

after is like at, except that one specifies a time span rather than an absolute time.

with_timeout span d returns a deferred that will become determined after either span elapses or d is determined, returning either `Timeout or `Result depending on which one succeeded first. At the time the returned deferred becomes determined, both things may have happened, in which case `Result is given preference.

with_timeout_exn span d ~error is like with_timeout, but raises if the timeout occurs. You should be careful with the Error.t you pass because its easy to allocate a large value that will be unused. To avoid this, you should use one of the lazy-creation functions in the Error module.

Events provide variants of run_at and run_after with the ability to abort or reschedule an event that hasn't yet happened. Once an event happens or is aborted, Async doesn't use any space for tracking it.

at_varying_intervals f ?stop returns a stream whose next element becomes determined by calling f () and waiting for that amount of time, and then looping to determine subsequent elements. The stream will end after stop becomes determined.

at_intervals interval ?start ?stop returns a stream whose elements will become determined at nonnegative integer multiples of interval after the start time, until stop becomes determined:

  start + 0 * interval
  start + 1 * interval
  start + 2 * interval
  start + 3 * interval
  ...

Note that only elements that are strictly in the future ever become determined. In particular, if start is not in the future, or start is not provided, then there will be no element before the interval has passed.

If the interval is too small or the CPU is too loaded, at_intervals will skip until the next upcoming multiple of interval after start.

every' ?start ?stop span f runs f () every span amount of time starting when start becomes determined and stopping when stop becomes determined. every' waits until the outcome of f () becomes determined before waiting for the next span.

It is guaranteed that if stop becomes determined, even during evaluation of f, then f will not be called again by a subsequent iteration of the loop.

It is an error for span to be nonpositive.

continue_on_error controls what should happen if f raises an exception. With ~continue_on_error:false, iteration only continues if f successfully returns a deferred and that deferred is determined. With ~continue_on_error:true, iteration also continues if f raises an exception. If f raises an exception asynchronously, this may cause us to proceed with the next iteration while the previous call to f is still running.

Exceptions raised by f are always sent to the monitor in effect when every' was called, even with ~continue_on_error:true.

If finished is supplied, every' will fill it once all of the following become determined: start, stop, and the outcome of the final call to f.

every ?start ?stop span f is every' ?start ?stop span (fun () -> f (); return ()).

run_at_intervals' ?start ?stop span f runs f() at increments of start + i * span for nonnegative integers i, until stop becomes determined. If the result of f is not determined fast enough then the next interval(s) are skipped so that there are never multiple concurrent invocations of f in flight.

Exceptions raised by f are always sent to monitor in effect when run_at_intervals' was called, even with ~continue_on_error:true.

run_at_intervals ?start ?stop ?continue_on_error span f is equivalent to:

  run_at_intervals' ?start ?stop ?continue_on_error span
    (fun () -> f (); return ()) 

duration_of f invokes f () and measures how long it takes from the invocation to after the deferred is determined.

Note that the measurement is not exact; because it involves an additional map on the deferred, the timing also includes the duration of jobs in the job queue when f () is determined.