Using Ractors and Making Ractors Usable
summary
Builds a Ractor-based Rack-compatible web server from a raw TCP GServer-style prototype into a Puma-like design: a receiver Ractor using fibers to buffer slow clients, a worker Ractor pool, and a scheduling handoff that returns responses to the original fiber. Uses async-http to parse into a Rack env but finds async-http is not Ractor-safe because a singleton console holds IO, so logging becomes a logger Ractor via RPC with refinements. Implementation is a few hundred lines and mostly works but hits thread↔Ractor wakeup and freezing/memory bugs that make production use unsafe.
AI-written summary · about
chapters (9)
- 0:00Why threads are dangerous
- 5:26Actors and Ractors ease concurrency
- 8:56TCP HTTP server with Ractors
- 11:45Rack-compatible server with Ractors
- 15:40Ractor-unsafe gems challenges
- 20:59Making Ractors production-ready
- 23:49Ruby needs better Ractor support
- 27:04How to use Ractors and why they matter for Ruby
- 29:09Q&A
related talks
28mCome Discuss Ractors and Concurrency with 'The Dude'!
28mRactors in Ruby 4.0: Message Passing Without the Pain
25mRactor Demonstration
30mRactor on Ruby 3.4
29mLearning Ractor with Raft
29mMillion-Agent Ruby: Ractor-Local GC in the Age of AI
27mParallel testing with Ractors - Putting CPU's to work
28mThread-Coordinated Ractors: The Pattern That Delivers