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.
Here is an example:
Output: 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.I was confused, and not alone: https://github.com/rails/rails/pull/30361.
So my conclusion about Fiber is always be careful with Fiber / Thread.current.
edit: style/explanation