Concurrency & Parallelism

The GVL (Global VM Lock) lets only one thread per Ractor execute Ruby code at a time. Threads speed up I/O-bound work, because blocking I/O and sleep release the lock, but not CPU-bound Ruby code.

Thread.new starts a block in a new thread and returns the Thread. join waits and returns that thread, or nil when its limit expires; value returns the block's result or re-raises its exception. Unjoined threads die when main exits.

A zombie is a child that has exited but whose status the parent never collected. Process.wait(pid) blocks and reaps it, Process.wait(pid, Process::WNOHANG) reaps only if it already exited, and Process.detach(pid) starts a thread that reaps it for you.

@hits += 1 is a separate read, add and write. The GVL lets one thread run Ruby at a time but does not keep a thread running across those steps, so a switch between the read and the write loses an increment.

Thread::Queue is a thread-safe FIFO whose pop blocks until an item arrives; Thread::SizedQueue also blocks push when full, bounding memory. Calling close lets workers drain the queue, after which pop returns nil and the workers exit.

Fiber.new creates a paused fiber. resume runs it until Fiber.yield, whose argument becomes resume's return value; the next resume's argument becomes Fiber.yield's return value. When the block ends, alive? is false and resuming raises FiberError.

fork copies the running Ruby process. Without a block it returns the child's pid in the parent and nil in the child; with a block, only the child runs it and then exits. Each process has its own GVL, so children run Ruby in parallel.

Core Ruby ships low-level primitives: Thread, Mutex, Queue, ConditionVariable, Monitor. The concurrent-ruby gem adds tested higher-level tools (thread pools, Concurrent::Promises futures, Concurrent::Map, atomic variables) with the same guarantees on every major Ruby implementation, so libraries build on it instead of hand-rolling them.

Async runs each connection as a task, a non-blocking fiber under a reactor that is the Fiber scheduler, so a socket wait parks only that task. Sync runs a block and returns its value. CPU-heavy work or blocking C calls stall every task.

CRuby gives each Ractor its own interpreter lock, so Ractors run on separate cores while threads inside one Ractor still take turns. The price is isolation: unshareable objects, global variables and class variables cannot be touched across Ractors.

Monitor is a reentrant lock: its owner may enter synchronize again, which a Mutex refuses with ThreadError. Its new_cond returns a condition variable with wait_while and wait_until, which loop on the predicate; Thread::ConditionVariable needs a Mutex and a hand-written loop.

The thread dies while others keep running. report_on_exception (default true) prints the error to $stderr at that moment; join or value re-raise it later. abort_on_exception (default false) re-raises it in the main thread immediately instead.

Thread#[] and #[]= are fiber-local: each fiber on a thread has its own store, so code running in another fiber sees nil. thread_variable_get and thread_variable_set are truly thread-local, shared by every fiber on that thread.

Concurrent::Map makes each individual read and write thread-safe, but map[key] ||= build is a read followed by a separate write, so two threads can both build and store. compute_if_absent(key) { build } checks and stores in one atomic step.

Concurrent::Promises.future { ... } starts a task immediately on the global :io pool; Promises.zip(a, b) waits for all and then { |x, y| ... } receives the values. On rejection value returns nil silently, while value! raises the error.

Fiber.set_scheduler installs an object that Ruby calls whenever a non-blocking fiber would block: a socket not ready calls io_wait, sleep calls kernel_sleep. The scheduler parks that fiber, runs others, and resumes it when the event loop reports readiness.

After fork, pages stay shared only until a process writes to them, and CRuby writes to heap pages constantly: allocating into free slots, promoting survivors to the old generation, filling string caches. Process.warmup does that work once in the parent before forking.

An object is shareable when it and everything it references is frozen, or it is inherently shareable (Integers, Symbols, classes). Ractor.make_shareable deep-freezes a graph, and # shareable_constant_value: literal does that for constants assigned from literals.

Not reliably. On CRuby the GVL keeps one Array#push or Hash#[]= from corrupting the object, but compound updates race, iteration can raise, and JRuby has no GVL at all. Guard shared collections with a Mutex or confine them to one thread.

Timeout.timeout makes a watcher thread raise into your thread with Thread#raise, so the exception can land on any line: mid-write, inside ensure cleanup, while a lock is held. Prefer the timeouts built into the I/O call itself.

FixedThreadPool.new(n) is a ThreadPoolExecutor with min_threads and max_threads both n and an unbounded queue. For push notifications, bound the queue with max_queue, choose a fallback_policy, handle errors inside each task, and shutdown plus wait_for_termination before exit.

Call Ractor.new(input) { |x| ... }; the arguments reach the isolated block like messages. r.join waits and returns the Ractor, r.value waits and returns the block's last value, and a crash surfaces as Ractor::RemoteError.

Fiber[:key] reads and Fiber[:key] = value writes the current fiber's storage. Each new fiber or thread starts with a copy of its creator's storage, so values flow down into enumerator fibers and tasks, but a child's writes never reach the parent.

Process._fork is the internal method that Kernel#fork, Process.fork and IO.popen("-") all call. Prepend a module to Process.singleton_class that overrides _fork, calls super and branches on the result: 0 in the child, the child's pid in the parent.

A Ractor::Port is a mailbox: any Ractor can send (or <<) to it without blocking, but only the Ractor that created it can receive. Ractor.select(*ports) waits on several ports or Ractors and returns [source, message].

AtomicFixnum holds one Integer with atomic increment, decrement and compare_and_set. AtomicReference holds any object and swaps it atomically. Its update block may run several times, so it must be side-effect free and return a new object rather than mutate the old one.