Currently the Thread
APIs behave in a way which obscures the root Fiber
from access.
There have been several new APIs added to support accessing the root Thread
local data.
If you consider that each Thread
has a root Fiber
, then accessing locals and the backtrace on that Fiber
object could return locals and the backtrace for the Thread
.
I have a WIP branch on top of Rubinius.
This returns a Fiber
wrapping the structures for the original Thread
.
Instead of using the new Thread
APIs, it would be possible to simply call methods on this object.
This returns an Array
of Fiber
objects currently owned by the Thread
.
If a Fiber
is moved to another Thread
, the Fiber
would no longer be returned in the previous Thread#fibers
call.
This returns an Array
of all executing or suspended Fiber
s.
This returns the value associated with this key on the Fiber
independent of which Fiber
is executing on the Thread
currently.
thread.thread_variable_get(key)
should be equivalent to thread.root_fiber[key]
.
This sets the value associated with this key on the Fiber
independent of which Fiber
is executing on the Thread
currently.
thread.thread_variable_set(key, value)
should be equivalent to thread.root_fiber[key] = value
.
This returns the keys associated with this Fiber
independent of which Fiber
is executing on the Thread
currently.
thread.thread_variables
should be equivalent to thread.root_fiber.keys
.
This returns the backtrace of this Fiber
independent of which Fiber
is executing on the Thread
currently.
This returns the execution stack of this Fiber
independent of which Fiber
is executing on the Thread
currently.
See Thread::Backtrace::Location
for more information.
This returns whether the Fiber
is still alive.
This returns the status of the Fiber
, whether it is executing or suspended.
This raises an exception inside the Fiber
when the Fiber
is next resumed.
I got a good example of the @celluloid use-case: https://gist.github.com/halorgium/c770d3cf27f6279e5e43