beware before using fibers because it won't access Thread.current[:vars].
So if you plan on going with fiber on an existing app, double check first if Thread.current[:vars] is a must have for you & you dependencies (ex: the I18n gem
Are you sure about that ?
If you search `Ruby Thread Locals are also Fiber-Local` there will be a blog post from 2012 about that, and the code sample works fine for me on ruby 2.5
I'm sorry, my previous comment was not clear. I should have written beware before using fibers because it won't access Thread.current[:vars] _as you might expect_.
Here is an example:
fiber = Fiber.new do # Thread.current locals are copied to the Fiber when fiber it is built
puts "1. #{Thread.current[:test]}"
Thread.current[:test] = false # the fiber has it's own stack, won't leak away
puts "2. #{Thread.current[:test]}"
end
Thread.current[:test] = true
fiber.resume
puts "3. #{Thread.current[:test]}"
Output:
1.
2. false
3. true
So fibers comes with their _own stack_, including threads locals, yes, but from _when_ you instantiated them. Not from Thread.current :/ Also writing Thread.current[] won't apply outside the Fiber.
So if you plan on going with fiber on an existing app, double check first if Thread.current[:vars] is a must have for you & you dependencies (ex: the I18n gem