
  -spec erlang:cancel_timer(TimerRef, Options) -> Result | ok
                               when
                                   TimerRef :: reference(),
                                   Async :: boolean(),
                                   Info :: boolean(),
                                   Option :: {async, Async} | {info, Info},
                                   Options :: [Option],
                                   Time :: non_neg_integer(),
                                   Result :: Time | false.

Since:
  OTP 18.0

  Cancels a timer that has been created by erlang:start_timer or 
  erlang:send_after. TimerRef identifies the timer, and was
  returned by the BIF that created the timer.

  Options:

  {async, Async}:
    Asynchronous request for cancellation. Async defaults to 
    false, which causes the cancellation to be performed
    synchronously. When Async is set to true, the cancel
    operation is performed asynchronously. That is, 
    cancel_timer() sends an asynchronous request for cancellation
    to the timer service that manages the timer, and then returns 
    ok.

  {info, Info}:
    Requests information about the Result of the cancellation. 
    Info defaults to true, which means the Result is given.
    When Info is set to false, no information about the result
    of the cancellation is given.

     • When Async is false: if Info is true, the 
       Result is returned by erlang:cancel_timer().
       otherwise ok is returned.

     • When Async is true: if Info is true, a message
       on the form {cancel_timer, TimerRef, Result} is sent
       to the caller of erlang:cancel_timer() when the
       cancellation operation has been performed, otherwise no
       message is sent.

  More Options may be added in the future.

  If Result is an integer, it represents the time in milliseconds
  left until the canceled timer would have expired.

  If Result is false, a timer corresponding to TimerRef could
  not be found. This can be either because the timer had expired,
  already had been canceled, or because TimerRef never
  corresponded to a timer. Even if the timer had expired, it does
  not tell you if the time-out message has arrived at its
  destination yet.

  Note:
    The timer service that manages the timer can be co-located
    with another scheduler than the scheduler that the calling
    process is executing on. If so, communication with the timer
    service takes much longer time than if it is located locally.
    If the calling process is in critical path, and can do other
    things while waiting for the result of this operation, or is
    not interested in the result of the operation, you want to use
    option {async, true}. If using option {async, false}, the
    calling process blocks until the operation has been performed.

  See also erlang:send_after/4, erlang:start_timer/4, and 
  erlang:read_timer/2.
