Feature #8215

Support accessing Fiber-locals and backtraces for a Fiber

Added by halorgium (Tim Carey-Smith) about 7 years ago. Updated 3 months ago.

Target version:


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 = do
Thread.current[:key] = "inside"
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:>))


0001-cont.c-fiber-local-accessors.patch (2.94 KB) 0001-cont.c-fiber-local-accessors.patch nobu (Nobuyoshi Nakada), 04/16/2013 05:03 PM

Updated by Eregon (Benoit Daloze) about 7 years ago

  • Category set to core
  • Status changed from Open to Closed

Thread#[] and friends access Fiber-local variables, as the doc says:

(Attribute Reference---Returns the value of a fiber-local variable (current
thread's root fiber if not explicitely inside a Fiber), using either a symbol
or a string name.)

This is unfortunate, as indeed one might expect it to be thread-local,
but it has been made fiber-local for safety.

In ruby >= 2.0.0, you have thread_variable_{get,set} and such for manipulating thread-local variables.
Not as nice, but at least the API is there. See #7097.

Updated by nobu (Nobuyoshi Nakada) about 7 years ago

  • Description updated (diff)
  • Status changed from Closed to Open

According to that rubinius issue tracker, it seems a feature request for Fiber#[] and Fiber#[]=.

Updated by Eregon (Benoit Daloze) about 7 years ago

Ah, sorry, I thought it was only misunderstanding of Thread#[] and such.

Updated by halorgium (Tim Carey-Smith) about 7 years ago

Yup, I am sorry if that was not clear!

I also am very interested in being able to get the backtrace of a Fiber too.

Should I open a new issue for Fiber#backtrace?

Updated by nobu (Nobuyoshi Nakada) almost 7 years ago

One ticket, one issue, please.

Updated by halorgium (Tim Carey-Smith) almost 7 years ago

I realised that this might be better in common-ruby.
I originally proposed the idea with RBX.
Could someone move it?

Updated by duerst (Martin Dürst) almost 7 years ago

On 2013/04/19 15:50, halorgium (Tim Carey-Smith) wrote:

Issue #8215 has been updated by halorgium (Tim Carey-Smith).

I realised that this might be better in common-ruby.

This isn't issue specific: I propose that just for the moment, issues
stay where they are. Once the overall directions are sorted out, we can
organize a general campaign to move issues wherever necessary. If we can
avoid it, we don't want to pollute each and every issue with individual
move requests.

Regards, Martin.


Updated by zzak (Zachary Scott) almost 7 years ago

  • Status changed from Open to Assigned
  • Assignee set to nobu (Nobuyoshi Nakada)

Updated by ioquatix (Samuel Williams) 3 months ago

matz (Yukihiro Matsumoto) I agree with adding all three APIs, Fiber#[], Fiber#[]= and Fiber#backtrace. Can you let me know if you are happy with these additions?

Updated by ioquatix (Samuel Williams) 3 months ago

  • Assignee changed from nobu (Nobuyoshi Nakada) to ioquatix (Samuel Williams)

Updated by Eregon (Benoit Daloze) 3 months ago

Fiber#[] and Fiber#[]= sounds fine, but what if somebody does:

some_fiber = { ... }; { some_fiber[:fiber_local] }?

I think that should raise or not be possible.
If it would return the value, it would imply synchronization on every access to fiber locals which seems unfortunate.

By making the API Fiber.[], we can avoid that entirely and have true fiber-locals, which can only be accessed by that Fiber:

Fiber[:my_fiber_local] = 42
value = Fiber[:my_fiber_local]
# no way to access fiber locals of another Fiber

I think for new APIs we should take the chance to make them only possible to use correctly.
We could even finally have Fiber and Thread local in a consistent way:

# access Fiber-local
# access Thread-local

Updated by ioquatix (Samuel Williams) 3 months ago

Eregon (Benoit Daloze) I agree with your points. I respect that you've studied a lot in your thesis so ultimately I'll defer to your judgement. But let me explain a bit more.

The reason for expanding the Fiber# interface is so that tools like async can show better debugging of all fibers.

Ideally it can show the backtrace, and allow the user to check fiber locals (and maybe even get a list of keys for debugging purposes).

I'd also be okay with adding Fiber.[] and so on, but that's kind of a separate issue.

Thread safety is not my concern, the function can be marked as thread unsafe, and maybe we can add detection of this and warn against it.

Also available in: Atom PDF