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

Issue #17325 has been updated by Eregon (Benoit Daloze).


This sounds like Thread#kill but for Fiber.
However, Fiber is cooperative so it seems this shouldn't be needed.

What's a concrete issue with Fiber#raise? It seems redundant with it to me.
If the application swallows Exception I think that's the application problem, and I think we should not add a second way to unwind a Fiber just for that.
The performance difference is likely not very relevant, as I expect exiting a Fiber is not a common operation, and most of the cost is likely unwinding the stack & running `ensure`.
Because this runs `ensure`, it's still possible for that Fiber to hang, or to raise another exception in `ensure` which can then be caught.
So, it's not a guarantee either.
`fiber.raise(Exception)` seems enough, and this seems to be only marginally different, at the cost of another method and yet another way to terminate a Fiber.

Regarding propagation, I'm not sure what's the difference, but exceptions in Fibers are propagated:
```
$ ruby -e 'f=Fiber.new { raise "foo" }; p((f.resume rescue $!))'
#<RuntimeError: foo>
```

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

* Author: nevans (Nicholas Evans)
* Status: Open
* Priority: Normal
----------------------------------------

Calling `Fiber#cancel` will force a fiber to return, skipping rescue and catch blocks but running all ensure blocks. It behaves as if a `break` or `return` were used to jump from the last suspension point to the top frame of the fiber. Control will be transferred to the canceled fiber so it can run its ensure blocks.

## Propagation from resuming to resumed fibers

Any non-root living fiber can be canceled and cancellation will propagate to child (resumed) fibers. In this way, a suspended task can be canceled even if it is e.g. resuming into an enumerator, and the enumerator will be canceled as well. Transfer of control should match #17221's *(much improved)* transfer/resume semantics. After the cancellation 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.

## Suspension of canceled fibers

Canceled fibers can still transfer control with `resume`, `yield`, and `transfer`, which may be necessary in order to release resources from `ensure` blocks. For simplicity, subsequent cancels will behave similarly to calling `break` or `return` inside an `ensure` block, and the last cancellation reason will overwrite earlier reasons.

## Alternatives

`Fiber#raise` could be used, but:
* Exceptions are bigger and slower than `break`.
* `#raise` can't (and shouldn't) be sent to resuming fibers. (It can't propagate.)
* Exceptions can be caught. This might be desirable, but that should be at the discretion of the calling fiber.

Catch/Throw could be used (with an anonymous `Object.new`), but:
* `catch` adds an extra stack frame.
* It would need to add `Fiber#throw` (or wrap/intercept `Fiber.yield`).
* A hypothetical `Fiber#throw` should probably only be allowed on yielding fibers (like `Fiber#resume`). (It wouldn't propagate.)

Implementation:  https://github.com/ruby/ruby/pull/3766



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

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>