Fiber
Async Ruby involves a concurrency model built around fibers, which are lightweight, user-managed units of execution. In contrast to traditional threads (which are scheduled and managed by the OS kernel), fibers yield control explicitly and are fully managed in userspace. This allows for more efficient resource sharing, especially for I/O-bound tasks.
Each fiber in Ruby schedules itself by yielding during I/O operations, is never interrupted mid-calculation, and shares resources through an event loop. This setup enables thousands of concurrent connections to be managed from userspace, without kernel involvement, and switching between fibers is both faster and consumes fewer resources than threads.
As a result, you can create vastly more fibers than threads and monitor many connections with less overhead and increased efficiency. For example, fibers can be created and switched between 17–18 times faster than threads, transitioning from microsecond to nanosecond timescales in some benchmarks. This is a significant improvement for I/O-heavy workloads where context switching cost is relevant fibers are managed entirely in userspace and are fast and efficient, and improved performance benchmarks.
Thread or Fiber?
Use threads for CPU-intensive work, tasks needing true memory/process isolation, or dealing with legacy C extensions that aren’t fiber-safe.
Use async (fiber/event loop-based) programming for I/O-bound operations, network API calls, streaming (like WebSockets or Server-Sent Events), and high-concurrency applications such as those that connect with Large Language Models (LLMs) threads vs async use cases. Comparing Ruby’s concurrency primitives:
The thing to keep in mind is that, as a general rule that doesn’t only apply to Ruby, CPU-bound and IO-bound work loads don’t mix well, and should ideally be handled by distinct systems. For small projects, you can likely tolerate the latency impact of collocating all your workloads in a one-size-fits-all system, but as you scale you will increasingly need to segregate IO-intensive workloads from CPU-intensive ones. - byroot
Review
Processes: Completely separate with their own memory space, suitable for isolation.
Threads: OS-scheduled, can be interrupted mid-execution, block independently on I/O, require significant OS resources, and need isolated resources like DB connections.
Fibers: Manually switched by yielding, not interruptible mid-calculation, and extremely lightweight, perfect for high numbers of concurrent I/O-bound tasks processes, threads, and fibers compared and thread OS scheduling and constraints.