Hacker News Reader

Comment by mfourcade | Hacker News Reader

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

View on HN

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.

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

Reply on news.ycombinator.com