final class ChainedCancelable extends AssignableCancelable
Represents a monix.execution.Cancelable whose underlying
cancelable reference can be swapped for another. It can
be "chained" to another ChainedCancelable, forwarding all
operations to it.
For most purposes it works like a OrderedCancelable:
val s = ChainedCancelable() s := c1 // sets the underlying cancelable to c1 s := c2 // swaps the underlying cancelable to c2 s.cancel() // also cancels c2 s := c3 // also cancels c3, because s is already canceled
However it can also be linked to another ChainedCancelable
reference, forwarding all requests to it:
val source = ChainedCancelable() val child1 = ChainedCancelable() val child2 = ChainedCancelable() // Hence forth forwards all operations on `child1` to `source` child1.chainTo(source) // Also forwarding all `child2` operations to `source`. // This happens because `child1` was linked to `source` first // but order matters, as `child2` will be linked directly // to `source` and not to `child1`, in order for `child1` to // be garbage collected if it goes out of scope ;-) child2.chainTo(child1) // Source will be updated with a new Cancelable ref child1 := Cancelable(() => println("Cancelling (1)")) // Source will be updated with another Cancelable ref child2 := Cancelable(() => println("Cancelling (2)")) source.cancel() //=> Cancelling (2)
This implementation is a special purpose AssignableCancelable,
much like StackedCancelable, to be used in flatMap
implementations that need it.
The problem that it solves in Monix's codebase is that various
flatMap implementations need to be memory safe.
By "chaining" cancelable references, we allow the garbage collector
to get rid of references created in a flatMap loop, the goal
being to consume a constant amount of memory. Thus this
implementation is used for
CancelableFuture.
The implementation is also relaxed about the thread-safety of
the forwardTo operation, treating it like a semi-final state and
using Java 8 getAndSet platform intrinsics for performance
reasons.
If unsure about what to use, then you probably don't need ChainedCancelable. Use OrderedCancelable or SingleAssignCancelable for most purposes.
- Source
- ChainedCancelable.scala
- Alphabetic
- By Inheritance
- ChainedCancelable
- AssignableCancelable
- Cancelable
- Serializable
- AnyRef
- Any
- Hide All
- Show All
- Public
- Protected
Value Members
- def :=(value: Cancelable): ChainedCancelable.this.type
Updates the internal reference of this assignable cancelable to the given value.
Updates the internal reference of this assignable cancelable to the given value.
If this cancelable is already canceled, then
valueis going to be canceled on assignment as well.- returns
this
- Definition Classes
- ChainedCancelable → AssignableCancelable
- def cancel(): Unit
Cancels the unit of work represented by this reference.
Cancels the unit of work represented by this reference.
Guaranteed idempotency - calling it multiple times should have the same side-effect as calling it only once. Implementations of this method should also be thread-safe.
- Definition Classes
- ChainedCancelable → Cancelable
- def forwardTo(other: ChainedCancelable): Unit
Chains this
ChainedCancelableto another reference, such that all operations are forwarded toother.Chains this
ChainedCancelableto another reference, such that all operations are forwarded toother.val source = ChainedCancelable() val child1 = ChainedCancelable() val child2 = ChainedCancelable() // Hence forth forwards all operations on `child1` to `source` child1.chainTo(source) // Also forwarding all `child2` operations to `source` // (this happens because `child1` was linked to `source` first // but order matters ;-)) child2.chainTo(child1) // Source will be updated with a new Cancelable ref child1 := Cancelable(() => println("Cancelling (1)")) // Source will be updated with another Cancelable ref child2 := Cancelable(() => println("Cancelling (2)")) source.cancel() //=> Cancelling (2)

This is the API documentation for the Monix library.
Package Overview
monix.execution exposes lower level primitives for dealing with asynchronous execution:
Atomictypes, as alternative tojava.util.concurrent.atomicmonix.catnap exposes pure abstractions built on top of the Cats-Effect type classes:
monix.eval is for dealing with evaluation of results, thus exposing Task and Coeval.
monix.reactive exposes the
Observablepattern:Observableimplementationsmonix.tail exposes Iterant for purely functional pull based streaming:
BatchandBatchCursor, the alternatives to Scala'sIterableandIteratorrespectively that we are using within Iterant's encodingYou can control evaluation with type you choose - be it Task, Coeval, cats.effect.IO or your own as long as you provide correct cats-effect or cats typeclass instance.