I've been looking at memory leaks today, and found this in the ThreadLocalVar docs in ruby-concurrency:
> Ruby's built-in thread-local variables leak forever the value set on each thread (unless set to nil explicitly).
Damn, that feels like a "Never use Thread.current ever", right? Very risky. Do y'all agree?
https://ruby-concurrency.github.io/concurrent-ruby/master/Concurrent/ThreadLocalVar.html
Followup: I had a hard time believing that values that you set in Thread.current[:thing] leak, so
I wrote a script that continuously spawns tons of threads and assigns Thread.current[:thing] with new objects.
Then another thread reported ObjectSpace stats every second.
I could find no evidence of a leak that way. False alarm?
But also, I noticed that Thread.current#[] is actually Fiber-local and not the same as Thread.thread_variable_[gs]et 🤔 I doubt that's any different leak-wise
@soulcutter I was surprised when you pointed that part of the documentation, and I'm pretty sure that was true in the past and it doesn't stand with current state of affairs leak-wise.
What I would do is compare your scripts with the specs for ThreadLocalVar, they surely have assertions for/about leaks.
@soulcutter this is probably still true:
> Each Ruby's built-in thread-local variable leaks some memory forever
Because you declare them like this:
Thread.current.thread_variable_set(:foo, 1)
That `: foo` lives forever since the symbols are not GC'd.
@esparta @soulcutter That last part used to be true, but Ruby has been able to GC symbols since 2.2.
https://www.ruby-lang.org/en/news/2014/12/25/ruby-2-2-0-released/
@soulcutter @jamie yeap, that's true I also forgot that symbols are GC-ables.
Then most of the old sayings are currently not so true anymore, I think an update on the documentation would be nice to have. Hope I can have time later.
@esparta symbols are basically interned strings though, so to leak that way I think you’d have to have unique symbols and not :foo in every thread. That’s my mental model anyway
