ruby-concurrency

Use threads with Net::HTTP since the GVL is released during blocking I/O, or use the async gem with Async::HTTP::Internet for fiber-based concurrency in a single thread. Threads are simpler; async scales to far more concurrent requests.

Use threads for I/O-bound work since the GVL is released during blocking calls. Use Ractors for CPU-bound pure-Ruby work, since each Ractor has its own GVL and runs in true parallel, but only shareable (frozen) objects can cross Ractor boundaries.

No. The GVL serializes bytecode execution but does not guarantee thread safety. Non-atomic operations like n += 1 or hash[k] ||= [] can interleave across GVL handoffs, so shared mutable state still requires a Mutex or atomic types.

Deadlocks occur when threads acquire multiple mutexes in different orders, or when a thread re-locks a non-reentrant Mutex it already holds. Acquire locks in a consistent global order, keep critical sections short, or use Monitor for re-entrant locking.

No. Most C extensions including pg and mysql2 are not Ractor-safe, and connection pools cannot be shared across Ractors. Each Ractor would need its own connection, making threads or processes a better fit for database-heavy workloads.

Use fibers for cooperative patterns like generators, lazy sequences, and state machines, or with a Fiber Scheduler (via the async gem) for high-concurrency I/O. Fibers cost ~4KB versus ~1MB per thread and never preempt, but provide no parallelism.