Skip to content

Support accessing Fiber-locals and backtraces for a Fiber #2200

Open
halorgium opened this Issue Mar 13, 2013 · 13 comments

5 participants

@halorgium

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.

/cc @evanphx

@halorgium

My gist has a hack which seems to work.

@stouset
stouset commented Mar 28, 2013

This behavior doesn't exist in MRI. Why do you expect that code to work?

@stouset
stouset commented Mar 28, 2013

Also, the entire justification for thread-local storage is to isolate data for a Thread (or Fiber) that shouldn't be accessed from outside of that Thread's (or Fiber's) scope. Violating that guarantee seems like a bad idea to me.

@halorgium

@stouset Thread#[] and Thread#[]= do exist and are safe to access.
My suggestion is purely to extend this access to Fibers which has several use-cases especially while debugging a concurrency framework such as @celluloid.

As to why I would expect this to work when MRI does not support this, my suggestion would be that MRI and all rubies could support this at some stage.

@stouset
stouset commented Mar 28, 2013

You're right, Thread#[] and Thread#[]= exist and are safe. Given that, it does make sense that Fiber could have its thread-local variables accessed. The most appropriate way seems like it would just delegate Fiber#[] and Fiber#[]= to Thread, since fibers have their own thread-local storage.

I'm working on a sample implementation. Correct me if I'm wrong, but I don't believe your approach uses the same storage for Fiber#[] as Thread#[].

@halorgium

@stouset I believe it does.
The storage is a read-through cache first for the current Fiber and then the underlying Thread.

More usefully would be the Fiber#backtrace method to match the Thread#backtrace method.

@ghost
ghost commented Mar 28, 2013

@halorgium You might want to open an issue on the MRI tracker too then, since I don't think Rubinius is going to diverge from the behavior of MRI unless MRI changes as well.

@halorgium

@robgleeson yer, I had talked briefly with @evanphx about this but you are probably right.

@stouset
stouset commented Mar 28, 2013

Closing, then. Please reopen if MRI considers implementing this feature. :)

@stouset stouset closed this Mar 28, 2013
@halorgium

For reference, I have filed an issue on the ruby-lang bug tracker: https://bugs.ruby-lang.org/issues/8215

@brixen
Rubinius member
brixen commented Jun 20, 2013

Let's leave this open until MRI decides whether or not they are implementing it. Rubinius can and has implemented supersets of MRI's APIs.

@brixen brixen reopened this Jun 20, 2013
@brixen
Rubinius member
brixen commented Jun 20, 2013

A convenient summary of the proposed Fiber API extensions https://gist.github.com/halorgium/5992cec8eba0b4c53492

@ioquatix

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.