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

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

Description updated

Added some other alternatives to the description.

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

* 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.)

We could use go-style "Context" objects that contain a "done?" queue/future.
* These would need to be explicitly passed around.
* Although their usage could be enforced via linters like rubocop, I think many developers would view them as optional unless it's explicitly built into their task-scheduler library. Some sort of cancel propagation mechanism is not optional for structured concurrency.
* This suffers the same problem as current wrappers: it works okay if your code uses the wrapper, but code that uses fibers without the wrapper is likely to be incompatible and introduce bugs (e.g. fibers that are released without running their `ensure` blocks).
* This make sense for a language like go which doesn't have exceptions but does have a convention of returning an "error" value. It feels out of place in ruby, IMO.

We could add a keyword option to `Fiber#raise` that gives it similar propagation semantics to this.
* IMO, the simplicity of `Fiber#raise` simply being a specialized version of `Fiber#resume` is worth preserving.
* The propagation changes alone are enough of a semantic difference to warrant a new method.

We could implement `Fiber#cancel` by raising `fiber.raise(FiberCancellationError)` on the bottom fiber and catching that exception during termination of the canceled fiber.
* This would have the "benefit" that the exception could be rescued.
* I might be wrong, but I think that doing this would be more complicated than the PR I've submitted.

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>