Utility to apply backpressure semantics to the execution of an Effect. Backpressure instances will apply a Backpressure.Strategy to the execution where each strategy works as follows:

Backpressure.Strategy.Lossy will mean that effects will not be run in the presence of backpressure, meaning the result will be None

Backpressure.Strategy.Lossless will mean that effects will run in the presence of backpressure, meaning the effect will semantically block until backpressure is alleviated

A purely functional synchronization primitive which represents a single value which may not yet be available.

When created, a Deferred is empty. It can then be completed exactly once, and never be made empty again.

get on an empty Deferred will block until the Deferred is completed. get on a completed Deferred will always immediately return its content.

complete(a) on an empty Deferred will set it to a, and notify any and all readers currently blocked on a call to get. complete(a) on a Deferred that has already been completed will not modify its content, and result in a failed F.

Albeit simple, Deferred can be used in conjunction with Ref to build complex concurrent behaviour and data structures like queues and semaphores.

Finally, the blocking mentioned above is semantic only, no actual threads are blocked by the implementation.

A mutable location, that is either empty or contains a value of type A.

It has the following fundamental atomic operations:

• put which fills the var if empty, or blocks (asynchronously) until the var is empty again
• tryPut which fills the var if empty. returns true if successful
• take which empties the var if full, returning the contained value, or blocks (asynchronously) otherwise until there is a value to pull
• tryTake empties if full, returns None if empty.
• read which reads the current value without touching it, assuming there is one, or otherwise it waits until a value is made available via put
• tryRead returns a variable if it exists. Implemented in the successor MVar2
• swap takes a value, replaces it and returns the taken value. Implemented in the successor MVar2
• isEmpty returns true if currently empty

The MVar is appropriate for building synchronization primitives and performing simple inter-thread communications. If it helps, it's similar with a BlockingQueue(capacity = 1), except that it doesn't block any threads, all waiting being done asynchronously (via Async or Concurrent data types, such as IO).

Given its asynchronous, non-blocking nature, it can be used on top of Javascript as well.

Inspired by Control.Concurrent.MVar from Haskell and by scalaz.concurrent.MVar.

The MVar2 is the successor of MVar with tryRead and swap. It was implemented separately only to maintain binary compatibility with MVar.

An asynchronous, concurrent mutable reference.

Provides safe concurrent access and modification of its content, but no functionality for synchronisation, which is instead handled by Deferred. For this reason, a Ref is always initialised to a value.

The default implementation is nonblocking and lightweight, consisting essentially of a purely functional wrapper over an AtomicReference.

A purely functional semaphore.

A semaphore has a non-negative number of permits available. Acquiring a permit decrements the current number of permits and releasing a permit increases the current number of permits. An acquire that occurs when there are no permits available results in semantic blocking until a permit becomes available.

Blocking acquires are cancelable if the semaphore is created with Semaphore.apply (and hence, with a Concurrent[F] instance). Blocking acquires are non-cancelable if the semaphore is created with Semaphore.async (and hence, with an Async[F] instance).

A fiber-based supervisor that monitors the lifecycle of all fibers that are started via its interface. The supervisor is managed by a singular fiber to which the lifecycles of all spawned fibers are bound.

Whereas Concurrent.background links the lifecycle of the spawned fiber to the calling fiber, starting a fiber via a Supervisor links the lifecycle of the spawned fiber to the supervisor fiber. This is useful when the scope of some fiber must survive the spawner, but should still be confined within some "larger" scope.

The fibers started via the supervisor are guaranteed to be terminated when the supervisor fiber is terminated. When a supervisor fiber is canceled, all active and queued fibers will be safely finalized before finalization of the supervisor is complete.

The following diagrams illustrate the lifecycle of a fiber spawned via Concurrent.start, Concurrent.background, and Supervisor. In each example, some fiber A is spawning another fiber B. Each box represents the lifecycle of a fiber. If a box is enclosed within another box, it means that the lifecycle of the former is confined within the lifecycle of the latter. In other words, if an outer fiber terminates, the inner fibers are guaranteed to be terminated as well.

start:

Fiber A lifecycle
+---------------------+
|                 |   |
+-----------------|---+
                  |
                  |A starts B
Fiber B lifecycle |
+-----------------|---+
|                 +   |
+---------------------+

background:

Fiber A lifecycle
+------------------------+
|                    |   |
| Fiber B lifecycle  |A starts B
| +------------------|-+ |
| |                  | | |
| +--------------------+ |
+------------------------+

Supervisor:

Supervisor lifecycle
+---------------------+
| Fiber B lifecycle   |
| +-----------------+ |
| |               + | |
| +---------------|-+ |
+-----------------|---+
                  |
                  | A starts B
Fiber A lifecycle |
+-----------------|---+
|                 |   |
+---------------------+

Supervisor should be used when fire-and-forget semantics are desired.

A mutable location, that is either empty or contains a value of type A.

It has the following fundamental atomic operations:

• put which fills the var if empty, or blocks (asynchronously) until the var is empty again
• tryPut which fills the var if empty. returns true if successful
• take which empties the var if full, returning the contained value, or blocks (asynchronously) otherwise until there is a value to pull
• tryTake empties if full, returns None if empty.
• read which reads the current value without touching it, assuming there is one, or otherwise it waits until a value is made available via put
• tryRead returns a variable if it exists. Implemented in the successor MVar2
• swap takes a value, replaces it and returns the taken value. Implemented in the successor MVar2
• isEmpty returns true if currently empty

The MVar is appropriate for building synchronization primitives and performing simple inter-thread communications. If it helps, it's similar with a BlockingQueue(capacity = 1), except that it doesn't block any threads, all waiting being done asynchronously (via Async or Concurrent data types, such as IO).

Given its asynchronous, non-blocking nature, it can be used on top of Javascript as well.

Inspired by Control.Concurrent.MVar from Haskell and by scalaz.concurrent.MVar.