Feature #17325


Adds Fiber#cancel, which forces a Fiber to break/return

Added by nevans (Nicholas Evans) about 2 years ago. Updated about 8 hours ago.

Target version:


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.


Fiber#raise could be used, but:

  • Can only raise on resumable fibers.
  • Cannot propagate cancellation down to resumed fibers.
  • 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, but:

  • We would need to add Fiber#throw (or wrap/intercept Fiber.yield).
  • A hypothetical Fiber#throw should probably have similar semantics to #resume and thus only be allowed on resumable fibers.
    • In that case, it wouldn't propagate down to resumed fibers.
  • catch adds an extra stack frame.

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 that placing it off to the side will give developers the impression that it is optional Some sort of cancel propagation mechanism is not optional for structured concurrency.
  • It should built into any task-scheduler library, which would allow application code to use it explicitly.
  • But this suffers the same problem as current Fiber wrappers: it works fine if your code uses the wrapper, but code that uses fibers without the wrapper can 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. Letting the fiber-task-scheduler mitigates that... for code that uses the fiber-task-scheduler.

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 using 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 mostly duplicate my PR, but with some added complexity around exception construction and catching.
  • It might be a good keyword option? e.g. Fiber#cancel(with_exception: [true,#exception,#to_str])

Just let the task-fiber-scheduler library handle this.

  • That's what I'm already doing now. It's mostly fine. It works in my code.
  • Putting it into ruby core should lead to a small performance boost on very commonly repeated code.
    • There's probably a better way to store the cancel_reason that doesn't require the overhead of adding another VALUE to rb_fiber_struct. Maybe it can be placed directly into errinfo?
  • Although the common cases can be handled via a trampoline fiber or #17221, there can still be situations where your application's fiber-scheduler library might not know about fibers created by other libraries. This adds interoperability to a common scenario.
  • Coroutine cancellation is IMO a core feature. It's important to have something like this for all applications and libraries to use as a baseline for interoperability.


Related issues 1 (0 open1 closed)

Related to Ruby master - Bug #17331: Let Fiber#raise work with transferring fibersClosedActions

Also available in: Atom PDF