Web framework behemoth Ruby on Rails is using the concurrent-ruby project for some internal book-keeping. I like that project. A bursting-packed tool bag of ready-to-use widgets and doodads – great, if you know how to use them.
One of those things is ThreadLocalVar. A variable? Local to a… thread?
Its documentation’s example is eloquent about what it does for you: In thread t1 we can read the ThreadLocalVar and have its starting value. Then, we can locally set and keep using that variable, without changing t2‘s value, nor the starting v‘s value.
Here, this is the example linked above:
v = ThreadLocalVar.new(14)
t1 = Thread.new do
v.value #=> 14
v.value = 1
v.value #=> 1
end
t2 = Thread.new do
v.value #=> 14
v.value = 2
v.value #=> 2
end
v.value #=> 14
I glanced at this, when Rails 6.1 is getting this new feature: being able to accept some deprecation warnings, while failing on all the other. See this Pull Request for usage in context.
I said book-keeping things, above: The only file in Rails which is currently using ThreadLocalVar is the one which manages deprecation warnings, ActiveSupport::Deprecation.
This was a short call-out of one of the Ruby Concurrency library’s many small tools, I can only invite you to explore it further. For example, by looking at these issues that are looking for a contributor.