Returns a Future that will be complete when all tasks have completed execution after a shutdown request, or the timeout occurs, or the thread awaiting the shutdown is interrupted, whichever happens first.

NOTE that this method does not block the current thread, unlike the similarly named method in Java's ExecutionService. This is because Monix has a strict non-blocking policy, due to the fact that other platforms like Javascript cannot block threads.

Because of the non-blocking requirement, this method returns a Future result. And on top of the JVM in order to block on such a result, you can just use Scala's Await.result:

import scala.concurrent.Await
import scala.concurrent.duration._
import monix.execution.Scheduler.global

val wasTerminated =
  Await.result(service.awaitTermination(30.seconds, global), Duration.Inf)

Given the asynchronous execution requirement, the awaitOn parameter is a Scheduler that's going to be used for terminating this service and completing our Future. Obviously we cannot reuse this service for awaiting on termination, but Monix's Scheduler.global can always be used for this.

Returns a monotonic clock measurement, if supported by the underlying platform.

This is the pure equivalent of Java's System.nanoTime, or of CLOCK_MONOTONIC from Linux's clock_gettime().

timer.clockMonotonic(NANOSECONDS)

The returned value can have nanoseconds resolution and represents the number of time units elapsed since some fixed but arbitrary origin time. Usually this is the Unix epoch, but that's not a guarantee, as due to the limits of Long this will overflow in the future (2⁶³ is about 292 years in nanoseconds) and the implementation reserves the right to change the origin.

The return value should not be considered related to wall-clock time, the primary use-case being to take time measurements and compute differences between such values, for example in order to measure the time it took to execute a task.

As a matter of implementation detail, Monix's Scheduler implementations use System.nanoTime and the JVM will use CLOCK_MONOTONIC when available, instead of CLOCK_REALTIME (see clock_gettime() on Linux) and it is up to the underlying platform to implement it correctly.

And be warned, there are platforms that don't have a correct implementation of CLOCK_MONOTONIC. For example at the moment of writing there is no standard way for such a clock on top of JavaScript and the situation isn't so clear cut for the JVM either, see:

• bug report
• concurrency-interest discussion on the X86 tsc register

The JVM tries to do the right thing and at worst the resolution and behavior will be that of System.currentTimeMillis.

The recommendation is to use this monotonic clock when doing measurements of execution time, or if you value monotonically increasing values more than a correspondence to wall-time, or otherwise prefer clockRealTime.

Returns the current time, as a Unix timestamp (number of time units since the Unix epoch).

This is the equivalent of Java's System.currentTimeMillis, or of CLOCK_REALTIME from Linux's clock_gettime().

The provided TimeUnit determines the time unit of the output, its precision, but not necessarily its resolution, which is implementation dependent. For example this will return the number of milliseconds since the epoch:

import scala.concurrent.duration.MILLISECONDS

scheduler.clockRealTime(MILLISECONDS)

N.B. the resolution is limited by the underlying implementation and by the underlying CPU and OS. If the implementation uses System.currentTimeMillis, then it can't have a better resolution than 1 millisecond, plus depending on underlying runtime (e.g. Node.js) it might return multiples of 10 milliseconds or more.

See clockMonotonic, for fetching a monotonic value that may be better suited for doing time measurements.

Schedules the given command for execution at some time in the future.

The command may execute in a new thread, in a pooled thread, in the calling thread, basically at the discretion of the Scheduler implementation.

The ExecutionModel is a specification of how run-loops and producers should behave in regards to executing tasks either synchronously or asynchronously.

Returns true if all tasks have completed following shut down. Note that isTerminated is never true unless shutdown was called first.

Reports that an asynchronous computation failed.

Schedules a periodic task that becomes enabled first after the given initial delay, and subsequently with the given period. Executions will commence after initialDelay then initialDelay + period, then initialDelay + 2 * period and so on.

If any execution of the task encounters an exception, subsequent executions are suppressed. Otherwise, the task will only terminate via cancellation or termination of the scheduler. If any execution of this task takes longer than its period, then subsequent executions may start late, but will not concurrently execute.

For example the following schedules a message to be printed to standard output approximately every 10 seconds with an initial delay of 5 seconds:

val task = scheduler.scheduleAtFixedRate(5, 10, TimeUnit.SECONDS, new Runnable {
  def run() = print("Repeated message")
})

// later if you change your mind ...
task.cancel()

Schedules a task to run in the future, after initialDelay.

For example the following schedules a message to be printed to standard output after 5 minutes:

val task = scheduler.scheduleOnce(5, TimeUnit.MINUTES, new Runnable {
  def run() = print("Hello, world!")
})

// later if you change your mind ...
task.cancel()

Schedules for execution a periodic task that is first executed after the given initial delay and subsequently with the given delay between the termination of one execution and the commencement of the next.

For example the following schedules a message to be printed to standard output every 10 seconds with an initial delay of 5 seconds:

val task = s.scheduleWithFixedDelay(5, 10, TimeUnit.SECONDS, new Runnable {
  def run() = print("Repeated message")
})

// later if you change your mind ...
task.cancel()

Initiates an orderly shutdown in which previously submitted tasks are executed, but no new tasks will be accepted.

This method does not wait for previously submitted tasks to complete execution. Use awaitTermination to do that.

Given a function that will receive the underlying ExecutionModel, returns a new Scheduler reference, based on the source, that exposes the transformed ExecutionModel when queried by means of the executionModel property.

This method enables reusing global scheduler references in a local scope, but with a slightly modified execution model to inject.

The contract of this method (things you can rely on):

1. the source Scheduler must not be modified in any way
2. the implementation should wrap the source efficiently, such that the result mirrors the source Scheduler in every way except for the execution model

Sample:

import monix.execution.Scheduler.global

implicit val scheduler = {
  val em = global.executionModel
  global.withExecutionModel(em.withAutoCancelableLoops(true))
}

Returns a new Scheduler that piggybacks on this, but uses the given exception reporter for reporting uncaught errors.

Sample:

import monix.execution.Scheduler.global
import monix.execution.UncaughtExceptionReporter

implicit val scheduler = {
  val r = UncaughtExceptionReporter { e =>
    e.printStackTrace()
  }
  global.withUncaughtExceptionReporter(r)
}

Exposes a set of flags that describes the Scheduler's features.