Feature #8215

Support accessing Fiber-locals and backtraces for a Fiber

Added by Tim Carey-Smith over 2 years ago. Updated about 2 years ago.

Assignee:Nobuyoshi Nakada


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[: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>))

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


#1 Updated by Benoit Daloze over 2 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.

#2 Updated by Nobuyoshi Nakada over 2 years ago

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

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

#3 Updated by Benoit Daloze over 2 years ago

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

#4 Updated by Tim Carey-Smith over 2 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?

#5 Updated by Nobuyoshi Nakada about 2 years ago

One ticket, one issue, please.

#6 Updated by Nobuyoshi Nakada about 2 years ago

More tests may be needed.

#7 Updated by Tim Carey-Smith about 2 years ago

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

#8 Updated by Martin Dürst about 2 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.

#9 Updated by Zachary Scott about 2 years ago

  • Assignee set to Nobuyoshi Nakada
  • Status changed from Open to Assigned

Also available in: Atom PDF