Ractor for true parallelism in Ruby - Deep Dive

Overview - Ractor for true parallelism

What is it?

Ractor is a feature in Ruby that allows programs to run multiple parts at the same time on different CPU cores. It creates isolated units called ractors that do not share memory, so they can truly run in parallel without interfering with each other. This helps Ruby programs use modern computers better by doing many tasks simultaneously. Ractors communicate by sending messages, keeping data safe and avoiding common problems with shared memory.

Why it matters

Without true parallelism, Ruby programs can only do one thing at a time, even on computers with many cores. This limits speed and efficiency, especially for heavy tasks like data processing or web servers. Ractor solves this by letting Ruby use all CPU cores safely and effectively. Without Ractor, Ruby developers had to rely on slower or more complex methods to run tasks in parallel, making programs slower and harder to write.

Where it fits

Before learning Ractor, you should understand Ruby basics like variables, methods, and threads. Knowing about concurrency and the problems with shared memory helps too. After Ractor, you can explore advanced parallel programming, performance tuning, and distributed systems in Ruby.

Mental Model

Core Idea

Ractor is like separate workers in isolated rooms who do tasks at the same time and only talk by passing notes, so they never get in each other's way.

Think of it like...

Imagine a kitchen with many chefs, each in their own room with their own ingredients and tools. They cook different dishes at the same time without bumping into each other. When they need to share a recipe or ingredient, they pass a written note through a small window. This way, everyone works fast and safely without mixing up ingredients or steps.

┌─────────────┐   message   ┌─────────────┐
│  Ractor 1   │───────────▶│  Ractor 2   │
│ (isolated) │   note     │ (isolated)  │
└─────────────┘           └─────────────┘

Each Ractor runs independently on its own CPU core.
No shared memory, only message passing.

Build-Up - 7 Steps

1

Foundation

Understanding Ruby's concurrency limits

Concept: Ruby threads run concurrently but not truly in parallel due to a global lock.

Ruby uses a Global Interpreter Lock (GIL) that lets only one thread run Ruby code at a time. This means even if you have many threads, they take turns running, so you don't get real parallelism on multiple CPU cores. Threads share memory, which can cause bugs if not handled carefully.

Result

Ruby threads can switch quickly but do not run Ruby code simultaneously on multiple cores.

Knowing Ruby's GIL limitation explains why true parallelism needs a different approach like Ractor.

2

Foundation

Introducing Ractor: isolated parallel units

Concept: Ractor creates isolated units that run truly in parallel without sharing memory.

A Ractor is like a separate Ruby interpreter running in parallel. It has its own memory and state, so it cannot accidentally change data in another Ractor. This isolation avoids the problems caused by shared memory in threads.

Result

Ractors can run Ruby code simultaneously on multiple CPU cores safely.

Understanding isolation is key to grasping how Ractor achieves true parallelism.

3

Intermediate

Communicating between Ractors with messages

🤔Before reading on: do you think Ractors share variables directly or communicate differently? Commit to your answer.

Concept: Ractors communicate by sending messages, not by sharing variables.

Since Ractors do not share memory, they send messages to each other using ports. Messages are copied or moved safely between Ractors. This message passing is the only way to exchange data, preventing race conditions and data corruption.

Result

You can coordinate work between Ractors without risking shared memory bugs.

Knowing message passing replaces shared variables helps avoid common concurrency errors.

4

Intermediate

Creating and using Ractors in Ruby code

🤔Before reading on: do you think Ractors run code immediately or wait for a start command? Commit to your answer.

Concept: You create a Ractor with a block of code that runs immediately in parallel.

Use Ractor.new { ... } to start a new Ractor. The block runs in parallel with the main program. You can send and receive messages using ractor.send and ractor.take. Ractors run independently until they finish or are stopped.

Result

Your Ruby program runs multiple tasks truly in parallel.

Understanding how to create and communicate with Ractors unlocks practical parallel programming.

5

Intermediate

Handling data safely with Ractor's copy-on-send

🤔Before reading on: do you think data sent between Ractors is shared or copied? Commit to your answer.

Concept: Data sent between Ractors is copied or moved to keep isolation intact.

When you send data to another Ractor, Ruby copies it or moves it if possible. This means each Ractor has its own copy, so changes in one do not affect the other. Some objects can be moved instead of copied for efficiency, but the original Ractor loses access.

Result

Data safety is guaranteed without locks or synchronization.

Knowing how data moves between Ractors explains why shared memory bugs disappear.

6

Advanced

Avoiding common pitfalls with Ractor communication

🤔Before reading on: do you think sending complex objects between Ractors always works smoothly? Commit to your answer.

Concept: Not all objects can be sent between Ractors; some raise errors or require special handling.

Certain objects like IO handles, mutexes, or singleton objects cannot be shared or sent. Trying to send them raises errors. You must design your program to send only safe, serializable data. Also, blocking operations inside Ractors can cause deadlocks if not managed carefully.

Result

Your Ractor programs run reliably without unexpected crashes or freezes.

Understanding Ractor's communication limits prevents subtle bugs in parallel programs.

7

Expert

Performance trade-offs and internal scheduling

🤔Before reading on: do you think Ractors always speed up programs linearly with more cores? Commit to your answer.

Concept: Ractors improve parallelism but have overhead and scheduling complexities that affect performance.

Creating and messaging between Ractors has costs. The Ruby scheduler manages Ractors on OS threads, balancing CPU use. Too many Ractors or heavy message passing can reduce gains. Also, some Ruby internal operations are not fully parallel yet. Profiling and tuning are needed for best results.

Result

You get faster programs but must balance Ractor use carefully.

Knowing Ractor's internal costs helps write efficient parallel Ruby code and avoid performance surprises.

Under the Hood

Ractor runs as a separate Ruby execution context with its own heap and thread. It uses OS threads to run truly in parallel on multiple CPU cores. Memory is not shared; instead, data is copied or moved between Ractors via message queues. The Ruby VM schedules Ractors cooperatively, switching between them and managing system resources. This isolation prevents race conditions and data corruption common in shared-memory concurrency.

Why designed this way?

Ruby's Global Interpreter Lock limited true parallelism, frustrating developers. Ractor was designed to provide safe parallelism without breaking Ruby's simplicity. Isolation avoids complex locking and synchronization bugs. Message passing is a proven model from other languages for safe concurrency. Alternatives like shared memory with locks were rejected due to complexity and error-proneness.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   Ractor 1    │       │   Ractor 2    │       │   Main Thread │
│  (own heap)  │       │  (own heap)  │       │  (own heap)   │
└──────┬────────┘       └──────┬────────┘       └──────┬────────┘
       │ message queue             │ message queue          │
       │──────────────▶           │◀───────────────        │
       │                          │                        │
       ▼                          ▼                        ▼
  OS Thread 1                OS Thread 2               OS Thread 0

Each Ractor runs isolated with its own memory and OS thread.
Messages pass through queues to communicate safely.

Myth Busters - 4 Common Misconceptions

Quick: Do Ractors share variables directly like threads? Commit yes or no.

Common Belief: Ractors share variables just like threads do, so you can access the same data from multiple Ractors.

Reality: Ractors do NOT share variables or memory. Each Ractor has its own copy of data, and communication happens only via message passing.

Why it matters: Assuming shared memory leads to bugs and crashes because Ractors cannot see or change each other's data directly.

Quick: Do Ractors always make your Ruby program faster? Commit yes or no.

Common Belief: Using Ractors automatically makes any Ruby program run faster by using all CPU cores.

Reality: Ractors can improve speed but add overhead. Poor design, too many Ractors, or heavy messaging can slow programs down.

Why it matters: Believing Ractors are a magic speed fix can cause inefficient code and wasted resources.

Quick: Can you send any Ruby object between Ractors without issues? Commit yes or no.

Common Belief: All Ruby objects can be sent between Ractors safely without errors.

Reality: Some objects like IO, Mutex, or singleton objects cannot be sent and will raise errors if attempted.

Why it matters: Trying to send unsupported objects causes crashes and hard-to-debug errors.

Quick: Does Ractor replace threads completely in Ruby? Commit yes or no.

Common Belief: Ractor is a full replacement for threads and should be used everywhere instead of threads.

Reality: Ractor complements threads but does not replace them. Threads are still useful for IO-bound tasks and shared-memory concurrency.

Why it matters: Misusing Ractors instead of threads can complicate code unnecessarily or reduce performance.

Expert Zone

1

Ractors cannot share mutable state, but frozen objects can be shared without copying, improving performance subtly.

2

Ruby's internal C extensions may not be fully Ractor-safe, requiring careful testing or alternative implementations.

3

Message passing between Ractors can be optimized by moving objects instead of copying, but this invalidates the sender's access, a subtle trade-off.

When NOT to use

Avoid Ractors when your program heavily relies on shared mutable state or third-party libraries that are not Ractor-safe. For IO-bound concurrency, Ruby threads or async frameworks like Async or EventMachine may be better. Also, for simple parallelism, processes or external job queues can be alternatives.

Production Patterns

In production, Ractors are used to parallelize CPU-heavy tasks like data processing, image manipulation, or background jobs. They are combined with message queues for communication and supervision patterns to restart failed Ractors. Developers often limit the number of Ractors to CPU cores and carefully design message protocols to avoid bottlenecks.

Connections

Actor Model (Computer Science)

Ractor is Ruby's implementation of the Actor Model pattern.

Understanding the Actor Model helps grasp Ractor's isolation and message passing as a proven concurrency design.

Microservices Architecture

Both use isolated units communicating via messages to achieve parallelism and fault tolerance.

Seeing Ractors as microservices inside a program clarifies how isolation and messaging improve reliability and scalability.

Human Teamwork in Separate Rooms

Ractors resemble teams working independently and coordinating only by passing notes.

This cross-domain view highlights how isolation and communication prevent conflicts and improve efficiency.

Common Pitfalls

#1 Trying to share mutable objects directly between Ractors.

Wrong approach:

shared_array = []
r1 = Ractor.new { shared_array << 1 }
r2 = Ractor.new { shared_array << 2 }

Correct approach:

r1 = Ractor.new { arr = []; arr << 1; arr }
r2 = Ractor.new { arr = []; arr << 2; arr }

Root cause:

Misunderstanding that Ractors do not share memory and that mutable objects must be isolated.

#2 Sending unsupported objects like IO handles between Ractors.

Wrong approach:

r = Ractor.new { |io| io.read }
r = Ractor.new { File.open('file.txt') }
r.send(File.open('file.txt'))

Correct approach:

r = Ractor.new { |path| File.read(path) }
r.send('file.txt')

Root cause:

Not knowing which objects are safe to send causes runtime errors.

#3 Creating too many Ractors without managing resources.

Wrong approach:

1000.times { Ractor.new { sleep(10) } }

Correct approach:

cores = Etc.nprocessors
cores.times { Ractor.new { sleep(10) } }

Root cause:

Ignoring system limits and overhead leads to resource exhaustion and poor performance.

Key Takeaways

Ractor provides true parallelism in Ruby by running isolated units that do not share memory.

Communication between Ractors happens only through message passing, avoiding shared-memory bugs.

Not all Ruby objects can be sent between Ractors; understanding safe data transfer is crucial.

Ractors improve performance but require careful design to avoid overhead and communication bottlenecks.

Ractor complements Ruby threads and fits into a broader concurrency and parallelism strategy.