Threads, callbacks, and execution context in Ruby
summary
Blocks behave like closures with captured self and local bindings that can change later, and they can run in different execution contexts and threads so the exact guarantee matters: a nuts client moves from one thread per subscription to a thread pool, benchmarks show several‑times faster for tens of thousands of subscriptions and a crash around 32,000 subscriptions prompted the change, which can silently break code that relies on Thread.current or on a stable call context.
AI-written summary · about
chapters (9)
- 0:00Introduction
- 5:08Ruby callbacks and worldview
- 7:13Ruby blocks as closures
- 9:23Changing execution context in blocks
- 11:13Blocks and thread-local data
- 13:00Case study: NATS Ruby client
- 15:54Thread pool behavior implications
- 16:36Thread context best practices
- 17:17Closing remarks
related talks
47mWhat All Rubyists Should Know About Threads
39mConcurrent Systems in Ruby
42mLook out! Gotchas of Using Threads in Ruby
30mAdvanced Multithreading in Ruby
36mIntroduction to Concurrency in Ruby
12mDon’t Be ‘Thread’-ened: Testing Multithreaded Code with Confidence
38mScaling Ruby with Actors, or How I Learned to Stop Worrying and Love Threads
54mConcurrency: Rubies, plural