[ruby-core:115911] [Ruby master Bug#20089] Fiber#kill transfers to root fiber

[ruby-core:115911] [Ruby master Bug#20089] Fiber#kill transfers to root fiber

[rmosolgo (Robert Mosolgo) via ruby-core]

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/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:115942] [Ruby master Bug#20089] Fiber#kill transfers to root fiber

[ioquatix (Samuel Williams) via ruby-core]

Issue #20089 has been updated by ioquatix (Samuel Williams).


Transfer is uni-directional and keeps no state about the caller. It's up to the caller to implement its own control flow if preferred. It's a low level operation which must be used more carefully.

```ruby
manager = Fiber.new do
  worker = Fiber.new do
    puts "2. Begin Worker"
    manager.transfer
    Fiber.current.kill
    puts "This should never print -- killed"
  ensure
    manager.transfer
  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"
```

By explicitly adding the flow control, we can achieve your desired output. Hope this helps.

----------------------------------------
Bug #20089: Fiber#kill transfers to root fiber
https://bugs.ruby-lang.org/issues/20089#change-105895

* 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/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:115966] [Ruby master Bug#20089] Fiber#kill transfers to root fiber

[rmosolgo (Robert Mosolgo) via ruby-core]

Issue #20089 has been updated by rmosolgo (Robert Mosolgo).


That definitely makes sense for a Fiber killing _itself_, but would you say that killing a _different_ Fiber should cause a fiber to transfer away? In my first script above, calling `worker.kill` causes the `manager` fiber to transfer. 

I looked a little deeper, it looks like this only happens when both Fibers have been started with `.transfer`. Here's a scenario with two different Fibers, one killing the other, and only the `.transfer`/`.transfer` case exits early: 

```ruby
puts "\n\nResume/Transfer"
fiber1 = Fiber.new {
  puts "1. Fiber1 Runs"
  fiber2 = Fiber.new {
    puts "2. Fiber2 Runs"
    fiber1.transfer
    puts "Never: Fiber2 is killed"
  }
  fiber2.transfer
  fiber2.kill
  puts "3. Fiber1 finishes"
}
fiber1.resume
puts "4. Exit"
# Resume/Transfer
# 1. Fiber1 Runs
# 2. Fiber2 Runs
# 3. Fiber1 finishes
# 4. Exit

puts "\n\nTransfer/Resume"
fiber1 = Fiber.new {
  puts "1. Fiber1 Runs"
  fiber2 = Fiber.new {
    puts "2. Fiber2 Runs"
    Fiber.yield
    puts "Never: Fiber2 is killed"
  }
  fiber2.resume
  fiber2.kill
  puts "3. Fiber1 finishes"
}
fiber1.transfer
puts "4. Exit"
# Transfer/Resume
# 1. Fiber1 Runs
# 2. Fiber2 Runs
# 3. Fiber1 finishes
# 4. Exit

puts "\n\nResume/Resume"
fiber1 = Fiber.new {
  puts "1. Fiber1 Runs"
  fiber2 = Fiber.new {
    puts "2. Fiber2 Runs"
    Fiber.yield
    puts "Never: Fiber2 is killed"
  }
  fiber2.resume
  fiber2.kill
  puts "3. Fiber1 finishes"
}
fiber1.resume
puts "4. Exit"
# Resume/Resume
# 1. Fiber1 Runs
# 2. Fiber2 Runs
# 3. Fiber1 finishes
# 4. Exit

puts "\n\nTransfer/Transfer"
fiber1 = Fiber.new {
  puts "1. Fiber1 Runs"
  fiber2 = Fiber.new {
    puts "2. Fiber2 Runs"
    fiber1.transfer
    puts "Never: Fiber2 is killed"
  }
  fiber2.transfer
  fiber2.kill
  puts "3. Fiber1 finishes"
}

fiber1.transfer
puts "4. Exit"
# Transfer/Transfer
# 1. Fiber1 Runs
# 2. Fiber2 Runs
# 4. Exit
```

Is there a more appropriate way to terminate `fiber2` in that case, while keeping control inside `fiber1`, or is this a bug?


----------------------------------------
Bug #20089: Fiber#kill transfers to root fiber
https://bugs.ruby-lang.org/issues/20089#change-105925

* 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/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:117462] [Ruby master Bug#20089] Fiber#kill transfers to root fiber

[ioquatix (Samuel Williams) via ruby-core]

Issue #20089 has been updated by ioquatix (Samuel Williams).


Thanks for the great examples.

On the surface of it, it looks like a bug. I'll need to check the logic of the implementation to see if we can improve the behaviour.

----------------------------------------
Bug #20089: Fiber#kill transfers to root fiber
https://bugs.ruby-lang.org/issues/20089#change-107849

* Author: rmosolgo (Robert Mosolgo)
* Status: Open
* 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/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:117463] [Ruby master Bug#20089] Fiber#kill transfers to root fiber

[ioquatix (Samuel Williams) via ruby-core]

Issue #20089 has been updated by ioquatix (Samuel Williams).

Assignee set to ioquatix (Samuel Williams)

----------------------------------------
Bug #20089: Fiber#kill transfers to root fiber
https://bugs.ruby-lang.org/issues/20089#change-107850

* Author: rmosolgo (Robert Mosolgo)
* Status: Open
* Assignee: ioquatix (Samuel Williams)
* 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/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:117565] [Ruby master Bug#20089] Fiber#kill transfers to root fiber

[ioquatix (Samuel Williams) via ruby-core]

Issue #20089 has been updated by ioquatix (Samuel Williams).


In the case of transfer, it may be possible to store the previous fiber, and on exiting a fiber, when no explicit transfer takes place, transfer back to the fiber that originally transferred into it. I think this is fairly compatible with existing code, but we'd need to survey the impact.

----------------------------------------
Bug #20089: Fiber#kill transfers to root fiber
https://bugs.ruby-lang.org/issues/20089#change-107963

* Author: rmosolgo (Robert Mosolgo)
* Status: Open
* Assignee: ioquatix (Samuel Williams)
* 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/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/