Fibers

Effect is a highly concurrent framework powered by fibers. Fibers are lightweight virtual threads with resource-safe cancellation capabilities, enabling many features in Effect.

In this section, you will learn the basics of fibers and get familiar with some of the powerful low-level operators that utilize fibers.

What Are Virtual Threads?

JavaScript is inherently single-threaded, meaning it executes code in a single sequence of instructions. However, modern JavaScript environments use an event loop to manage asynchronous operations, creating the illusion of multitasking. In this context, virtual threads, or fibers, are logical threads simulated by the Effect runtime. They allow concurrent execution without relying on true multi-threading, which is not natively supported in JavaScript.

How Fibers work

All effects in Effect are executed by fibers. If you didn’t create the fiber yourself, it was created by an operation you’re using (if it’s concurrent) or by the Effect runtime system.

A fiber is created any time an effect is run. When running effects concurrently, a fiber is created for each concurrent effect.

Even if you write “single-threaded” code with no concurrent operations, there will always be at least one fiber: the “main” fiber that executes your effect.

Effect fibers have a well-defined lifecycle based on the effect they are executing.

Every fiber exits with either a failure or success, depending on whether the effect it is executing fails or succeeds.

Effect fibers have unique identities, local state, and a status (such as done, running, or suspended).

To summarize:

• An Effect is a higher-level concept that describes an effectful computation. It is lazy and immutable, meaning it represents a computation that may produce a value or fail but does not immediately execute.
• A fiber, on the other hand, represents the running execution of an Effect. It can be interrupted or awaited to retrieve its result. Think of it as a way to control and interact with the ongoing computation.

The Fiber Data Type

The Fiber data type in Effect represents a “handle” on the execution of an effect.

Here is the general form of a Fiber:

        ┌─── Represents the success type
        │        ┌─── Represents the error type
        │        │
        ▼        ▼
Fiber<Success, Error>

This type indicates that a fiber:

• Succeeds and returns a value of type Success
• Fails with an error of type Error

Fibers do not have an Requirements type parameter because they only execute effects that have already had their requirements provided to them.

Forking Effects

You can create a new fiber by forking an effect. This starts the effect in a new fiber, and you receive a reference to that fiber.

Example (Forking a Fiber)

In this example, the Fibonacci calculation is forked into its own fiber, allowing it to run independently of the main fiber. The reference to the fib10Fiber can be used later to join or interrupt the fiber.

1
import { Effect } from "effect"
2

3
const fib = (n: number): Effect.Effect<number> =>
4
  n < 2 ? Effect.succeed(n) : Effect.zipWith(fib(n - 1), fib(n - 2), (a, b) => a + b)
5

6
//      ┌─── Effect<RuntimeFiber<number, never>, never, never>
7
//      ▼
8
const fib10Fiber = Effect.fork(fib(10))

Joining Fibers

One common operation with fibers is joining them. By using the Fiber.join function, you can wait for a fiber to complete and retrieve its result. The joined fiber will either succeed or fail, and the Effect returned by join reflects the outcome of the fiber.

Example (Joining a Fiber)

1
import { Effect, Fiber } from "effect"
2

3
const fib = (n: number): Effect.Effect<number> =>
4
  n < 2 ? Effect.succeed(n) : Effect.zipWith(fib(n - 1), fib(n - 2), (a, b) => a + b)
5

6
//      ┌─── Effect<RuntimeFiber<number, never>, never, never>
7
//      ▼
8
const fib10Fiber = Effect.fork(fib(10))
9

10
const program = Effect.gen(function* () {
11
  // Retrieve the fiber
12
  const fiber = yield* fib10Fiber
13
  // Join the fiber and get the result
14
  const n = yield* Fiber.join(fiber)
15
  console.log(n)
16
})
17

18
Effect.runFork(program) // Output: 55

Awaiting Fibers

The Fiber.await function is a helpful tool when working with fibers. It allows you to wait for a fiber to complete and retrieve detailed information about how it finished. The result is encapsulated in an Exit value, which gives you insight into whether the fiber succeeded, failed, or was interrupted.

Example (Awaiting Fiber Completion)

1
import { Effect, Fiber } from "effect"
2

3
const fib = (n: number): Effect.Effect<number> =>
4
  n < 2 ? Effect.succeed(n) : Effect.zipWith(fib(n - 1), fib(n - 2), (a, b) => a + b)
5

6
//      ┌─── Effect<RuntimeFiber<number, never>, never, never>
7
//      ▼
8
const fib10Fiber = Effect.fork(fib(10))
9

10
const program = Effect.gen(function* () {
11
  // Retrieve the fiber
12
  const fiber = yield* fib10Fiber
13
  // Await its completion and get the Exit result
14
  const exit = yield* Fiber.await(fiber)
15
  console.log(exit)
16
})
17

18
Effect.runFork(program)
19
/*
20
Output:
21
{ _id: 'Exit', _tag: 'Success', value: 55 }
22
*/

Interruption Model

While developing concurrent applications, there are several cases that we need to interrupt the execution of other fibers, for example:

1. A parent fiber might start some child fibers to perform a task, and later the parent might decide that, it doesn’t need the result of some or all of the child fibers.

2. Two or more fibers start race with each other. The fiber whose result is computed first wins, and all other fibers are no longer needed, and should be interrupted.

3. In interactive applications, a user may want to stop some already running tasks, such as clicking on the “stop” button to prevent downloading more files.

4. Computations that run longer than expected should be aborted by using timeout operations.

5. When we have an application that perform compute-intensive tasks based on the user inputs, if the user changes the input we should cancel the current task and perform another one.

Polling vs. Asynchronous Interruption

When it comes to interrupting fibers, a naive approach is to allow one fiber to forcefully terminate another fiber. However, this approach is not ideal because it can leave shared state in an inconsistent and unreliable state if the target fiber is in the middle of modifying that state. Therefore, it does not guarantee internal consistency of the shared mutable state.

Instead, there are two popular and valid solutions to tackle this problem:

1. Semi-asynchronous Interruption (Polling for Interruption): Imperative languages often employ polling as a semi-asynchronous signaling mechanism, such as Java. In this model, a fiber sends an interruption request to another fiber. The target fiber continuously polls the interrupt status and checks whether it has received any interruption requests from other fibers. If an interruption request is detected, the target fiber terminates itself as soon as possible.

   With this solution, the fiber itself handles critical sections. So, if a fiber is in the middle of a critical section and receives an interruption request, it ignores the interruption and defers its handling until after the critical section.

   However, one drawback of this approach is that if the programmer forgets to poll regularly, the target fiber can become unresponsive, leading to deadlocks. Additionally, polling a global flag is not aligned with the functional paradigm followed by Effect.

2. Asynchronous Interruption: In asynchronous interruption, a fiber is allowed to terminate another fiber. The target fiber is not responsible for polling the interrupt status. Instead, during critical sections, the target fiber disables the interruptibility of those regions. This is a purely functional solution that doesn’t require polling a global state. Effect adopts this solution for its interruption model, which is a fully asynchronous signaling mechanism.

   This mechanism overcomes the drawback of forgetting to poll regularly. It is also fully compatible with the functional paradigm because in a purely functional computation, we can abort the computation at any point, except during critical sections where interruption is disabled.

Interrupting Fibers

Fibers can be interrupted if their result is no longer needed. This action immediately stops the fiber and safely runs all finalizers to release any resources.

Like Fiber.await, the Fiber.interrupt function returns an Exit value that provides detailed information about how the fiber ended.

Example (Interrupting a Fiber)

1
import { Effect, Fiber } from "effect"
2

3
const program = Effect.gen(function* () {
4
  // Fork a fiber that runs indefinitely, printing "Hi!"
5
  const fiber = yield* Effect.fork(
6
    Effect.forever(Effect.log("Hi!").pipe(Effect.delay("10 millis"))),
7
  )
8
  yield* Effect.sleep("30 millis")
9
  // Interrupt the fiber and get an Exit value detailing how it finished
10
  const exit = yield* Fiber.interrupt(fiber)
11
  console.log(exit)
12
})
13

14
Effect.runFork(program)
15
/*
16
Output:
17
timestamp=... level=INFO fiber=#1 message=Hi!
18
timestamp=... level=INFO fiber=#1 message=Hi!
19
{
20
  _id: 'Exit',
21
  _tag: 'Failure',
22
  cause: {
23
    _id: 'Cause',
24
    _tag: 'Interrupt',
25
    fiberId: {
26
      _id: 'FiberId',
27
      _tag: 'Runtime',
28
      id: 0,
29
      startTimeMillis: ...
30
    }
31
  }
32
}
33
*/

By default, the effect returned by Fiber.interrupt waits until the fiber has fully terminated before resuming. This ensures that no new fibers are started before the previous ones have finished, a behavior known as “back-pressuring.”

If you do not require this waiting behavior, you can fork the interruption itself, allowing the main program to proceed without waiting for the fiber to terminate:

Example (Forking an Interruption)

1
import { Effect, Fiber } from "effect"
2

3
const program = Effect.gen(function* () {
4
  const fiber = yield* Effect.fork(
5
    Effect.forever(Effect.log("Hi!").pipe(Effect.delay("10 millis"))),
6
  )
7
  yield* Effect.sleep("30 millis")
8
  const _ = yield* Effect.fork(Fiber.interrupt(fiber))
9
  console.log("Do something else...")
10
})
11

12
Effect.runFork(program)
13
/*
14
Output:
15
timestamp=... level=INFO fiber=#1 message=Hi!
16
timestamp=... level=INFO fiber=#1 message=Hi!
17
Do something else...
18
*/

There is also a shorthand for background interruption called Fiber.interruptFork.

1
import { Effect, Fiber } from "effect"
2

3
const program = Effect.gen(function* () {
4
  const fiber = yield* Effect.fork(
5
    Effect.forever(Effect.log("Hi!").pipe(Effect.delay("10 millis"))),
6
  )
7
  yield* Effect.sleep("30 millis")
8
  // const _ = yield* Effect.fork(Fiber.interrupt(fiber))
9
  const _ = yield* Fiber.interruptFork(fiber)
10
  console.log("Do something else...")
11
})
12

13
Effect.runFork(program)
14
/*
15
Output:
16
timestamp=... level=INFO fiber=#1 message=Hi!
17
timestamp=... level=INFO fiber=#1 message=Hi!
18
Do something else...
19
*/

Composing Fibers

The Fiber.zip and Fiber.zipWith functions allow you to combine two fibers into one. The resulting fiber will produce the results of both input fibers. If either fiber fails, the combined fiber will also fail.

Example (Combining Fibers with Fiber.zip)

In this example, both fibers run concurrently, and the results are combined into a tuple.

1
import { Effect, Fiber } from "effect"
2

3
const program = Effect.gen(function* () {
4
  // Fork two fibers that each produce a string
5
  const fiber1 = yield* Effect.fork(Effect.succeed("Hi!"))
6
  const fiber2 = yield* Effect.fork(Effect.succeed("Bye!"))
7

8
  // Combine the two fibers using Fiber.zip
9
  const fiber = Fiber.zip(fiber1, fiber2)
10

11
  // Join the combined fiber and get the result as a tuple
12
  const tuple = yield* Fiber.join(fiber)
13
  console.log(tuple)
14
})
15

16
Effect.runFork(program)
17
/*
18
Output:
19
[ 'Hi!', 'Bye!' ]
20
*/

Another way to compose fibers is by using Fiber.orElse. This function allows you to provide an alternative fiber that will execute if the first one fails. If the first fiber succeeds, its result will be returned. If it fails, the second fiber will run instead, and its result will be returned regardless of its outcome.

Example (Providing a Fallback Fiber with Fiber.orElse)

1
import { Effect, Fiber } from "effect"
2

3
const program = Effect.gen(function* () {
4
  // Fork a fiber that will fail
5
  const fiber1 = yield* Effect.fork(Effect.fail("Uh oh!"))
6
  // Fork another fiber that will succeed
7
  const fiber2 = yield* Effect.fork(Effect.succeed("Hurray!"))
8
  // If fiber1 fails, fiber2 will be used as a fallback
9
  const fiber = Fiber.orElse(fiber1, fiber2)
10
  const message = yield* Fiber.join(fiber)
11
  console.log(message)
12
})
13

14
Effect.runFork(program)
15
/*
16
Output:
17
Hurray!
18
*/

Lifetime of Child Fibers

When we fork fibers, depending on how we fork them we can have four different lifetime strategies for the child fibers:

1. Fork With Automatic Supervision. If we use the ordinary Effect.fork operation, the child fiber will be automatically supervised by the parent fiber. The lifetime child fibers are tied to the lifetime of their parent fiber. This means that these fibers will be terminated either when they end naturally, or when their parent fiber is terminated.

2. Fork in Global Scope (Daemon). Sometimes we want to run long-running background fibers that aren’t tied to their parent fiber, and also we want to fork them in a global scope. Any fiber that is forked in global scope will become daemon fiber. This can be achieved by using the Effect.forkDaemon operator. As these fibers have no parent, they are not supervised, and they will be terminated when they end naturally, or when our application is terminated.

3. Fork in Local Scope. Sometimes, we want to run a background fiber that isn’t tied to its parent fiber, but we want that fiber to live in the local scope. We can fork fibers in the local scope by using Effect.forkScoped. Such fibers can outlive their parent fiber (so they are not supervised by their parents), and they will be terminated when their life end or their local scope is closed.

4. Fork in Specific Scope. This is similar to the previous strategy, but we can have more fine-grained control over the lifetime of the child fiber by forking it in a specific scope. We can do this by using the Effect.forkIn operator.

Fork with Automatic Supervision

Effect follows a structured concurrency model, where child fibers’ lifetimes are tied to their parent. Simply put, the lifespan of a fiber depends on the lifespan of its parent fiber.

Example (Automatically Supervised Child Fiber)

In this scenario, the parent fiber spawns a child fiber that repeatedly prints a message every second. The child fiber will be terminated when the parent fiber completes.

1
import { Effect, Console, Schedule } from "effect"
2

3
// Child fiber that logs a message repeatedly every second
4
const child = Effect.repeat(Console.log("child: still running!"), Schedule.fixed("1 second"))
5

6
const parent = Effect.gen(function* () {
7
  console.log("parent: started!")
8
  // Child fiber is supervised by the parent
9
  yield* Effect.fork(child)
10
  yield* Effect.sleep("3 seconds")
11
  console.log("parent: finished!")
12
})
13

14
Effect.runFork(parent)
15
/*
16
Output:
17
parent: started!
18
child: still running!
19
child: still running!
20
child: still running!
21
parent: finished!
22
*/

This behavior can be extended to any level of nested fibers, ensuring a predictable and controlled fiber lifecycle.

Fork in Global Scope (Daemon)

You can create a long-running background fiber using Effect.forkDaemon. This type of fiber, known as a daemon fiber, is not tied to the lifecycle of its parent fiber. Instead, its lifetime is linked to the global scope. A daemon fiber continues running even if its parent fiber is terminated and will only stop when the global scope is closed or the fiber completes naturally.

Example (Creating a Daemon Fiber)

This example shows how daemon fibers can continue running in the background even after the parent fiber has finished.

1
import { Effect, Console, Schedule } from "effect"
2

3
// Daemon fiber that logs a message repeatedly every second
4
const daemon = Effect.repeat(Console.log("daemon: still running!"), Schedule.fixed("1 second"))
5

6
const parent = Effect.gen(function* () {
7
  console.log("parent: started!")
8
  // Daemon fiber running independently
9
  yield* Effect.forkDaemon(daemon)
10
  yield* Effect.sleep("3 seconds")
11
  console.log("parent: finished!")
12
})
13

14
Effect.runFork(parent)
15
/*
16
Output:
17
parent: started!
18
daemon: still running!
19
daemon: still running!
20
daemon: still running!
21
parent: finished!
22
daemon: still running!
23
daemon: still running!
24
daemon: still running!
25
daemon: still running!
26
daemon: still running!
27
...etc...
28
*/

Even if the parent fiber is interrupted, the daemon fiber will continue running independently.

Example (Interrupting the Parent Fiber)

In this example, interrupting the parent fiber doesn’t affect the daemon fiber, which continues to run in the background.

1
import { Effect, Console, Schedule, Fiber } from "effect"
2

3
// Daemon fiber that logs a message repeatedly every second
4
const daemon = Effect.repeat(Console.log("daemon: still running!"), Schedule.fixed("1 second"))
5

6
const parent = Effect.gen(function* () {
7
  console.log("parent: started!")
8
  // Daemon fiber running independently
9
  yield* Effect.forkDaemon(daemon)
10
  yield* Effect.sleep("3 seconds")
11
  console.log("parent: finished!")
12
}).pipe(Effect.onInterrupt(() => Console.log("parent: interrupted!")))
13

14
// Program that interrupts the parent fiber after 2 seconds
15
const program = Effect.gen(function* () {
16
  const fiber = yield* Effect.fork(parent)
17
  yield* Effect.sleep("2 seconds")
18
  yield* Fiber.interrupt(fiber) // Interrupt the parent fiber
19
})
20

21
Effect.runFork(program)
22
/*
23
Output:
24
parent: started!
25
daemon: still running!
26
daemon: still running!
27
parent: interrupted!
28
daemon: still running!
29
daemon: still running!
30
daemon: still running!
31
daemon: still running!
32
daemon: still running!
33
...etc...
34
*/

Fork in Local Scope

Sometimes we want to create a fiber that is tied to a local scope, meaning its lifetime is not dependent on its parent fiber but is bound to the local scope in which it was forked. This can be done using the Effect.forkScoped operator.

Fibers created with Effect.forkScoped can outlive their parent fibers and will only be terminated when the local scope itself is closed.

Example (Forking a Fiber in a Local Scope)

In this example, the child fiber continues to run beyond the lifetime of the parent fiber. The child fiber is tied to the local scope and will be terminated only when the scope ends.

1
import { Effect, Console, Schedule } from "effect"
2

3
// Child fiber that logs a message repeatedly every second
4
const child = Effect.repeat(Console.log("child: still running!"), Schedule.fixed("1 second"))
5

6
//      ┌─── Effect<void, never, Scope>
7
//      ▼
8
const parent = Effect.gen(function* () {
9
  console.log("parent: started!")
10
  // Child fiber attached to local scope
11
  yield* Effect.forkScoped(child)
12
  yield* Effect.sleep("3 seconds")
13
  console.log("parent: finished!")
14
})
15

16
// Program runs within a local scope
17
const program = Effect.scoped(
18
  Effect.gen(function* () {
19
    console.log("Local scope started!")
20
    yield* Effect.fork(parent)
21
    // Scope lasts for 5 seconds
22
    yield* Effect.sleep("5 seconds")
23
    console.log("Leaving the local scope!")
24
  }),
25
)
26

27
Effect.runFork(program)
28
/*
29
Output:
30
Local scope started!
31
parent: started!
32
child: still running!
33
child: still running!
34
child: still running!
35
parent: finished!
36
child: still running!
37
child: still running!
38
Leaving the local scope!
39
*/

Fork in Specific Scope

There are some cases where we need more fine-grained control, so we want to fork a fiber in a specific scope. We can use the Effect.forkIn operator which takes the target scope as an argument.

Example (Forking a Fiber in a Specific Scope)

In this example, the child fiber is forked into the outerScope, allowing it to outlive the inner scope but still be terminated when the outerScope is closed.

1
import { Console, Effect, Schedule } from "effect"
2

3
// Child fiber that logs a message repeatedly every second
4
const child = Effect.repeat(Console.log("child: still running!"), Schedule.fixed("1 second"))
5

6
const program = Effect.scoped(
7
  Effect.gen(function* () {
8
    yield* Effect.addFinalizer(() => Console.log("The outer scope is about to be closed!"))
9

10
    // Capture the outer scope
11
    const outerScope = yield* Effect.scope
12

13
    // Create an inner scope
14
    yield* Effect.scoped(
15
      Effect.gen(function* () {
16
        yield* Effect.addFinalizer(() => Console.log("The inner scope is about to be closed!"))
17
        // Fork the child fiber in the outer scope
18
        yield* Effect.forkIn(child, outerScope)
19
        yield* Effect.sleep("3 seconds")
20
      }),
21
    )
22

23
    yield* Effect.sleep("5 seconds")
24
  }),
25
)
26

27
Effect.runFork(program)
28
/*
29
Output:
30
child: still running!
31
child: still running!
32
child: still running!
33
The inner scope is about to be closed!
34
child: still running!
35
child: still running!
36
child: still running!
37
child: still running!
38
child: still running!
39
child: still running!
40
The outer scope is about to be closed!
41
*/

When do Fibers run?

Forked fibers begin execution after the current fiber completes or yields.

Example (Late Fiber Start Captures Only One Value)

In the following example, the changes stream only captures a single value, 2. This happens because the fiber created by Effect.fork starts after the value is updated.

1
import { Effect, SubscriptionRef, Stream, Console } from "effect"
2

3
const program = Effect.gen(function* () {
4
  const ref = yield* SubscriptionRef.make(0)
5
  yield* ref.changes.pipe(
6
    // Log each change in SubscriptionRef
7
    Stream.tap((n) => Console.log(`SubscriptionRef changed to ${n}`)),
8
    Stream.runDrain,
9
    // Fork a fiber to run the stream
10
    Effect.fork,
11
  )
12
  yield* SubscriptionRef.set(ref, 1)
13
  yield* SubscriptionRef.set(ref, 2)
14
})
15

16
Effect.runFork(program)
17
/*
18
Output:
19
SubscriptionRef changed to 2
20
*/

If you add a short delay with Effect.sleep() or call Effect.yieldNow(), you allow the current fiber to yield. This gives the forked fiber enough time to start and collect all values before they are updated.

Example (Delay Allows Fiber to Capture All Values)

1
import { Effect, SubscriptionRef, Stream, Console } from "effect"
2

3
const program = Effect.gen(function* () {
4
  const ref = yield* SubscriptionRef.make(0)
5
  yield* ref.changes.pipe(
6
    // Log each change in SubscriptionRef
7
    Stream.tap((n) => Console.log(`SubscriptionRef changed to ${n}`)),
8
    Stream.runDrain,
9
    // Fork a fiber to run the stream
10
    Effect.fork,
11
  )
12

13
  // Allow the fiber a chance to start
14
  yield* Effect.sleep("100 millis")
15

16
  yield* SubscriptionRef.set(ref, 1)
17
  yield* SubscriptionRef.set(ref, 2)
18
})
19

20
Effect.runFork(program)
21
/*
22
Output:
23
SubscriptionRef changed to 0
24
SubscriptionRef changed to 1
25
SubscriptionRef changed to 2
26
*/