Issue #20089 has been reported by rmosolgo (Robert Mosolgo). ---------------------------------------- Bug #20089: Fiber#kill transfers to root fiber https://bugs.ruby-lang.org/issues/20089 * Author: rmosolgo (Robert Mosolgo) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I was hoping to use `Fiber#kill` to clean up formerly `.transfer`-d Fibers and work around https://bugs.ruby-lang.org/issues/20081, but I found that `Fiber#kill` has a similar control flow jump behavior. Is this on purpose, or a bug? Here's a script to test the behavior: ```ruby manager = Fiber.new do worker = Fiber.new do puts "2. Begin Worker" manager.transfer puts "This should never print -- killed" end puts "1. Transfer to Worker" worker.transfer puts "3. Killing Worker" worker.kill puts "4. Finished manager" end manager.transfer puts "5. Finished script" ``` I expected items `1` through `5` to be printed in order, but in fact, `4` is never printed: ``` $ ruby fiber_transfer_test.rb 1. Transfer to Worker 2. Begin Worker 3. Killing Worker 5. Finished script ``` It seems like `worker.kill` is transferring control to the top-level fiber instead of giving it back to `manager`. I also tried having the thread kill _itself_, hoping it would return to the fiber that originally `.transfer`ed to it, but it also seems to jump out: ```ruby manager = Fiber.new do worker = Fiber.new do puts "2. Begin Worker" manager.transfer Fiber.current.kill puts "This should never print -- killed" end puts "1. Transfer to Worker" worker.transfer puts "3. Killing Worker" worker.transfer puts "4. Finished manager" end manager.transfer puts "5. Finished script" ``` Prints: ``` 1. Transfer to Worker 2. Begin Worker 3. Killing Worker 5. Finished script ``` -- https://bugs.ruby-lang.org/