From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id E61D21F66F for ; Sun, 15 Nov 2020 22:59:09 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 231E8120B45; Mon, 16 Nov 2020 07:58:25 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 7684A120B43 for ; Mon, 16 Nov 2020 07:58:23 +0900 (JST) Received: by filterdrecv-p3iad2-6d658b4b48-q8k5h with SMTP id filterdrecv-p3iad2-6d658b4b48-q8k5h-20-5FB1B2B7-F 2020-11-15 22:59:03.090365805 +0000 UTC m=+172965.176488187 Received: from herokuapp.com (unknown) by geopod-ismtpd-3-3 (SG) with ESMTP id z6uhfU24R6GEyWN9c-0oMQ for ; Sun, 15 Nov 2020 22:59:03.047 +0000 (UTC) Date: Sun, 15 Nov 2020 22:59:03 +0000 (UTC) From: eregontp@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 76736 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 17325 X-Redmine-Issue-Author: nevans X-Redmine-Sender: Eregon X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?KippOI8ZHtTweq7XfQzW93937kJ4QNWwSBuHnaMEcr3zfPnfyrE0vXkSfJLsW1?= =?us-ascii?Q?BcMaTBv+9Lhog5KBcLZ=2FGKFVi+=2FnoZRUqyHyK83?= =?us-ascii?Q?JaAigkEge7USMk5kZYUkL77MlPSWWMf2kH1dNY=2F?= =?us-ascii?Q?dh4ot0C3S0VIhuvCYjK3+eVP9GBtjBoutHQHKTm?= =?us-ascii?Q?YfrbyySkmffT4RUpu8NPOHPfO0a0CuWv4JLSpW5?= =?us-ascii?Q?+u0Wil3Up0nh2UT+Y=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 100863 Subject: [ruby-core:100863] [Ruby master Feature#17325] Adds Fiber#cancel, which forces a Fiber to break/return X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" 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 $!))' # ``` ---------------------------------------- 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/