You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
JRuby version (jruby -v) and command line (flags, JRUBY_OPTS, etc)
Operating system and platform (e.g. uname -a)
Charless-Air:ruby-io cremes$ ruby -v
jruby 9.1.15.0 (2.3.3) 2017-12-07 929fde8 Java HotSpot(TM) 64-Bit Server VM 25.144-b01 on 1.8.0_144-b01 +jit [darwin-x86_64]
Charless-Air:ruby-io cremes$ uname -a
Darwin Charless-Air 16.7.0 Darwin Kernel Version 16.7.0: Mon Nov 13 21:56:25 PST 2017; root:xnu-3789.72.11~1/RELEASE_X86_64 x86_64
Expected Behavior
Describe your expectation of how JRuby should behave, perhaps by showing how CRuby/MRI behaves.
Provide an executable Ruby script or a link to an example repository.
I should be able to ping pong between a thread's root fiber and a new fiber using Fiber#transfer. This behavior means that Ruby's Fiber is providing full coroutine behavior. However, it fails early with a complaint about transferring fibers between threads. This is NOT happening.
My guess is that since JRuby wraps a fiber in its own thread, there is some confusion over the proper "thread owner" ancestry of the fiber. That is, Ruby main thread T0 has root fiber F0 (wrapped in its own thread P0 by runtime). Main thread creates a new fiber F1 (wrapped in thread P1 by runtime) and attempts to transfer to it. Since both threads were created in Ruby thread T0, this should work. However, it's failing maybe due to the fiber(s) believing they were created by thread P0 or P1 (which are not visible from Ruby).
Full code to reproduce along with output from MRI 2.5.0, Rubinius 3.86, and JRuby 9.1.15.0.
The problem appears to be transferring back to the main thread's "root fiber". Our data structure for Fiber tracks the "real" parent thread, and the root fiber was not being set up with any parent thread. Fixing this to make it its own parent appears to fix your example.
Environment
Provide at least:
jruby -v
) and command line (flags, JRUBY_OPTS, etc)uname -a
)Charless-Air:ruby-io cremes$ ruby -v
jruby 9.1.15.0 (2.3.3) 2017-12-07 929fde8 Java HotSpot(TM) 64-Bit Server VM 25.144-b01 on 1.8.0_144-b01 +jit [darwin-x86_64]
Charless-Air:ruby-io cremes$ uname -a
Darwin Charless-Air 16.7.0 Darwin Kernel Version 16.7.0: Mon Nov 13 21:56:25 PST 2017; root:xnu-3789.72.11~1/RELEASE_X86_64 x86_64
Expected Behavior
I should be able to ping pong between a thread's root fiber and a new fiber using
Fiber#transfer
. This behavior means that Ruby's Fiber is providing full coroutine behavior. However, it fails early with a complaint about transferring fibers between threads. This is NOT happening.My guess is that since JRuby wraps a fiber in its own thread, there is some confusion over the proper "thread owner" ancestry of the fiber. That is, Ruby main thread T0 has root fiber F0 (wrapped in its own thread P0 by runtime). Main thread creates a new fiber F1 (wrapped in thread P1 by runtime) and attempts to transfer to it. Since both threads were created in Ruby thread T0, this should work. However, it's failing maybe due to the fiber(s) believing they were created by thread P0 or P1 (which are not visible from Ruby).
Full code to reproduce along with output from MRI 2.5.0, Rubinius 3.86, and JRuby 9.1.15.0.
https://gist.github.com/chuckremes/14c9ef06efc0bc62b9dc5b588c06719f
Actual Behavior
Charless-Air:ruby-io cremes$ ruby -v
rubinius 3.86.c109 (2.3.1 65a8656f 2017-12-29 5.0.0) [x86_64-darwin16.7.0]
The text was updated successfully, but these errors were encountered: