From: eregontp@... Date: 2020-04-24T12:08:18+00:00 Subject: [ruby-core:98057] [Ruby master Feature#8215] Support accessing Fiber-locals and backtraces for a Fiber Issue #8215 has been updated by Eregon (Benoit Daloze). > We already have situations in JRuby and TruffleRuby where unsynchronized access to shared mutable state can cause a crash or data corruption. So why is this different? Let's not introduce more bugs (and IMHO those bugs should be fixed), especially if these methods are supposed to access *local* state, which means state you may not access from any other Thread. It's probably fine to access locals of another Fiber of the same Thread though, that's not racy since Fibers of a Thread don't run simultaneously. So I'd be OK with that, if we raise when trying to access locals of a Fiber belonging to a different Thread. Is there a reason you want to store this state in Fiber locals and not e.g., in instance variables of the Fiber object? ---------------------------------------- Feature #8215: Support accessing Fiber-locals and backtraces for a Fiber https://bugs.ruby-lang.org/issues/8215#change-85285 * Author: halorgium (Tim Carey-Smith) * Status: Assigned * Priority: Normal * Assignee: ioquatix (Samuel Williams) ---------------------------------------- =begin As part of debugging celluloid, I have been wanting to diagnose where the Fibers are running and their various locals. I would expect the following to work. Thread.current[:key] = "outside" fiber = Fiber.new do Thread.current[:key] = "inside" Fiber.yield end fiber.resume fiber[:key] == "inside" # true fiber.backtrace # ... I also wonder whether (({Fiber#[]})) should be implemented, so (({Fiber.current[:key]})) is possible. For reference, here is the issue on the rubinius issue tracker: ((<"github/rubinius/rubinius/2200"|URL:https://github.com/rubinius/rubinius/issues/2200>)) =end ---Files-------------------------------- 0001-cont.c-fiber-local-accessors.patch (2.94 KB) -- https://bugs.ruby-lang.org/ Unsubscribe: