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.