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-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.1 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_PASS shortcircuit=no autolearn=ham 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 4C1B61F453 for ; Wed, 1 May 2019 15:12:19 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id D3ED8120ABE; Thu, 2 May 2019 00:12:13 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 740E7120A82 for ; Thu, 2 May 2019 00:12:10 +0900 (JST) Received: by filter0113p3las1.sendgrid.net with SMTP id filter0113p3las1-8254-5CC9B72F-4 2019-05-01 15:11:43.138572745 +0000 UTC m=+498336.741834643 Received: from herokuapp.com (unknown [54.159.201.37]) by ismtpd0002p1iad2.sendgrid.net (SG) with ESMTP id 0tFfmpKgTZWYH9ehRbJxog for ; Wed, 01 May 2019 15:11:42.962 +0000 (UTC) Date: Wed, 01 May 2019 15:11:43 +0000 (UTC) From: eregontp@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 67998 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 14736 X-Redmine-Issue-Author: ioquatix 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?KippOI8ZHtTweq7XfQzW93937kJ4QNWwSBuHnaMEcr3uh1SRUH4oQ0HF=2FLunWE?= =?us-ascii?Q?1N+saLwPAnac86F6783+nejd0C+if649hMLntnc?= =?us-ascii?Q?CimqhwAK0ARrDR0Zzx6ySXYHswvQcnbkyla3KIO?= =?us-ascii?Q?oC7DDLv=2FCysENaCRM1ytcScivVz658Pfsx=2FqA+3?= =?us-ascii?Q?xM0RmgPLrVWXEAJtRJYAapLCSkJglneSzWA=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 92515 Subject: [ruby-core:92515] [Ruby trunk Feature#14736] Thread selector for flexible cooperative fiber based concurrency 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 #14736 has been updated by Eregon (Benoit Daloze). We discussed this a bit at the Ruby developer meeting before RubyKaigi and @matz asked me to share my opinion on the bug tracker. I also attended @ioquatix's talk at RubyKaigi and it was quite convincing. Basically, the main outcome for me is that we can do pretty much all of "AutoFiber" #13618, with much less complexity and a completely trivial patch (see https://github.com/ruby/ruby/pull/1870/files). With those hooks on "waiting for IO", we can do the scheduling entirely in Ruby and we have a lot more flexibility on what we want to do. We don't need to introduce a third kind of mix of Fiber and Thread, we just reuse Fiber and Fiber#transfer. We can simply use nio4r for efficient polling of file descriptors which is already portable. AutoFiber (#13618) sounds nice, but it's only one model with no extension points or flexibility, and it's a lot of code to maintain in each Ruby implementation. There are no silver bullets for concurrency, flexibility is key to best adapt to the case at hand. If the concern is to propose a concrete concurrency model for Ruby 3, I think it's fine to show examples on how to do it with external gems (e.g., nio4r, async). That just shows we live as a Ruby community. There are open issues for both proposals, e.g., how to handle disk IO such as `File.read` (which always reports "ready" by select() but might take a while on a large file), Mutex, ConditionVariable#wait, Queue#push and other blocking operations. For instance, it sounds natural to schedule another Fiber in Mutex#lock if the Mutex is already locked, and then we'd need some way to notify the scheduler once the Mutex is unlocked to schedule the first Fiber. Also, should we try to handle IOs which are not set manually set as #nonblock=true? Maybe we should make all sockets and pipes nonblock by default? They don't seem to be in 2.6.2. Or is that intended as a mechanism so that scheduling is only triggered on IOs manually set as nonblock? One question is how can we scope this functionality so that Fiber scheduling only happens in code where it's intended? That's related to atomicity and concurrency concerns in the AutoFiber thread. The selectors from the PR are per-Thread, but maybe we want something finer-grained. I think the async gem shows one way to do that with a block: `Async { ... }` from https://github.com/socketry/async#async Since we can control the selectors/scheduler in Ruby, it's easy to tune this and for instance introduce a construct to only perform blocking calls without scheduling inside a given block. In other words, this API gives us the power to fine-tune scheduling so that we can ensure the semantics wanted for a given application. ---------------------------------------- Feature #14736: Thread selector for flexible cooperative fiber based concurrency https://bugs.ruby-lang.org/issues/14736#change-77879 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- Ruby concurrency can be greatly enhanced by concurrent, deterministic IO. Fibers have been shown many times to be a great abstraction for this purpose. The retain normal code flow and don't require any kind of Thread synchronisation. They are enjoyable to write code with because you don't have to concern yourself with thread synchronisation or other complicated issues. The basic idea is that if some operation would block, it yields the Fiber, and other Fibers within the thread can continue to execute. There are a number of ways to implement this. Here is a proof of concept to amend the existing `rb_io_wait_readable`/`rb_io_wait_writable`. https://github.com/ruby/ruby/pull/1870 This design minimally affects the Ruby implementation and allows flexibility for selector implementation. With a small amount of work, we can support EventMachine (65 million downloads), NIO4r (21 million downloads). It would be trivial to back port. This PR isn't complete but I am seeking feedback. If it's a good idea, I will do my best to see it through to completion, including support for EventMachine and NIO4r. ---Files-------------------------------- port_scanner_threadlet.rb (925 Bytes) -- https://bugs.ruby-lang.org/