From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 13B291F404 for ; Tue, 14 Aug 2018 18:25:58 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id D8D8E120959; Wed, 15 Aug 2018 03:25:55 +0900 (JST) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by neon.ruby-lang.org (Postfix) with ESMTPS id CC9DB120932 for ; Wed, 15 Aug 2018 03:25:39 +0900 (JST) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id D4D9D1F404; Tue, 14 Aug 2018 18:25:37 +0000 (UTC) Date: Tue, 14 Aug 2018 18:25:37 +0000 From: Eric Wong To: ruby-core@ruby-lang.org Message-ID: <20180814182537.GB32360@dcvr> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-ML-Name: ruby-core X-Mail-Count: 88486 Subject: [ruby-core:88486] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid 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" danieldasilvaferreira@gmail.com wrote: > normalperson@yhbt.net wrote: > > > I am thinking of adding preemption support to this feature for > compatibility with 1.8 > > non-preemptive vs preemptive. > coroutines are non-preemptive. > threads are preemptive. > Are we talking about having the two behaviours in this new feature? "Preemptive" is a minor detail, here. I don't care that much about it; it is a single bit flag we can implement at a later time. > > So this made me think of "Thread::Coro" > > What is the logic behind "Coro"? Short for "Coroutine". > > Other ideas: Thread::CSP or Thread::Sequential (probably too long) > > Does it mean we will have the CSP algebraic operators available? No, so probably "CSP" is not a good name for this. I am not a formal nomenclature person; I make engineering decisions which are ultimately sympathetic to: a) compatibility with existing codebases b) hardware limitations > Reading through this conversation it feels we are dealing with a feature with a lot of concepts incorporated into it. > Can we get a resume of all the functionality we expect to have? It shouldn't be any different than how Ruby threads are currently used. Only creation is different: "Thread.new {}" vs "Thread::Coro.new {}" > Or even feature comparison with other languages. I don't know feature details of other languages well enough to comment. Basically, this is re-introduction of green threads from Ruby 1.8; but I still want to keep benefits of 1.9-2.5 native threads. See my other reply to ko1 in this thread [ruby-core:88484] for pros/cons of both: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/88484 (or ) However, I don't know other languages (Haskell/GHC, Go, Erlang) well enough to describe APIs; but I know they have lightweight threads (M:N) which use less memory than native 1:1 threads. What I don't like about transparent M:N threading is (AFAIK for those languages) they don't give programmers a choice about when to use native vs green. M:N threading is fine when you want parallelism in SMP because timeslices are predictable when your bottleneck is CPU/memory on SMP systems. Implementations of M:N falls down when you want parallelism across multiple filesystems because timeslices become unpredictable. This is a problem for low-end SSDs and HDDs especially, but also network filesystems and USB sticks. Making the Ruby VM transparently aware of multiple filesystems and bottlenecks/characteristics of each mountpoint may be out-of-scope. I'm not aware of any language runtime takes that into account; so we can leave that to the Ruby user. Also, C Ruby generally sucks at taking advantage of SMP because of GVL. However, we are currently great at dealing with parallelism across multiple filesystems because of 1:1 threads. > I believe we must do that kind of documentation to show to the community in a clear way the new ruby async possibilities. > I'm willing to help in planning and developing it. The goal is to make migration/testing easy and minimize rewrite cost. So programmers can gsub(/\bThread\.new\b/, "Thread::Coro.new") in places where only 1:N threads make sense (see [ruby-core:88484])