[ruby-core:100850] [Ruby master Feature#17325] Adds Fiber#cancel, which forces a Fiber to break/return

[nicholas.evans@gmail.com]

Issue #17325 has been updated by nevans (Nicholas Evans).


This is my first big foray into the ruby C API, so I hope it makes sense what I was trying to do. Did I handle `vm_fiber_break` and `fiber_start` appropriately? Is there is somewhere more appropriate to save the cancel reason than a new `VALUE` on `rb_fiber_struct`? E.g. could I safely assign the canceled fiber's `ec->errinfo` from the calling Fiber, instead of using `cancel_reason`?

When this compiles, it warns about:
```
vm_insnhelper.h:251:1: warning: ‘vm_call_iseq_optimizable_p’ defined but not used [-Wunused-function]
  251 | vm_call_iseq_optimizable_p(const struct rb_callinfo *ci, const struct rb_callcache *cc)     
```
So I'm probably doing something wrong there, too.

----------------------------------------
Feature #17325: Adds Fiber#cancel, which forces a Fiber to break/return
https://bugs.ruby-lang.org/issues/17325#change-88491

* Author: nevans (Nicholas Evans)
* Status: Open
* Priority: Normal
----------------------------------------
This skips rescue and catch blocks but runs all ensure blocks. It can be run on any living fiber, and propagates cancellation to child (resumed) fibers.

Basically, I want it to behave as if you called `break` or `return` to jump all the way to the top frame of the fiber from wherever it is.. Exceptions might be too heavy-weight, can't (and shouldn't) be sent to resuming fibers, and can be caught. This can also be emulated via `catch/throw` with an anonymous `Object.new`, but that adds an extra stack frame, and implementing it reliably requires interception of `Fiber.yield`, e.g. adding a `Fiber.throw` (analogous to `Fiber.raise`) which also shouldn't be sent to resuming fibers.

I tried to match the new _(much improved!)_ transfer/resume switch semantics with cancel propagation. When the cancelation propagates all the way to the bottom of the fiber resume stack, the last fiber in the chain will then be resumed. Resuming fibers will not run until they are yielded back into.

I think it's important to allow future `resume` and `transfer` out of a canceled fiber, in case it's necessary to close resources from `ensure` blocks. However, may have chosen the wrong behavior for multiple `cancels` on a `canceling`. I chose to use the same propagate/resume/transfer semantics but _not `break` again_ after subsequent cancels. On second thought, I think it should behave more like a standard `break`, and do exactly the same thing that `break` or `return` would normally do if they are called from an `ensure` block. I'll update this patch with that behavior when I'm able to.

---Files--------------------------------
0001-Added-Fiber-cancel-which-forces-a-Fiber-to-return.patch (14.4 KB)


-- 
https://bugs.ruby-lang.org/