Review hub management implementation

[st0012]

Related discussions:

• https://twitter.com/_solnic_/status/1410539769495527432
• Thread variables are not accessible  dry-rb/dry-effects#82 (comment)

[singpolyma]

Found this because I was reviewing the code and surprised to see a thread local variable used. I would expect each Fiber, as a separate logical context and stack, to have a different hub, but I see this was done to solve some bug related to the way Rails uses Fibers? So maybe it needs to be an option...

[st0012]

@singpolyma I'd like to give each fiber its own hub as well. But as long as users still use thread as a minimum concurrency unit instead of Fiber, it'll cause issues like #1374.

As for adding a fiber-based option, I don't plan to do that right now. But I'll revisit this issue when we start the implementation for version 5.0.

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[sl0thentr0py]

we should revisit this when we implement the new hub-free scope system.
fwiw, opentelemtry itself uses a fiber local, if I understand correctly

https://github.com/open-telemetry/opentelemetry-ruby/blob/ff9a7d3af31ad83ed6e07445a9e1609bec53d779/api/lib/opentelemetry/context.rb#L126-L128