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=-4.1 required=3.0 tests=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.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 640C01F609 for ; Wed, 28 Nov 2018 10:44:27 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id E468D1212AD; Wed, 28 Nov 2018 19:44:23 +0900 (JST) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by neon.ruby-lang.org (Postfix) with ESMTPS id 25499120AF9 for ; Wed, 28 Nov 2018 19:44:19 +0900 (JST) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 386051F609; Wed, 28 Nov 2018 10:44:17 +0000 (UTC) Date: Wed, 28 Nov 2018 10:44:17 +0000 From: Eric Wong To: ruby-core@ruby-lang.org Message-ID: <20181128104417.vh4vbi4pzlv4cphx@dcvr> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-ML-Name: ruby-core X-Mail-Count: 90112 Subject: [ruby-core:90112] 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" matz@ruby-lang.org wrote: > The first proposal of auto fiber was fibers with implicit context switch on I/O operations. They are fundamentally not fibers, but threads (without time slice context switching). Since they switch context less often, they are less dangerous than normal threads. But now it seems to be changed to user level preemptive threads with time slice switching. Hi Matz, thanks for your response. There is no time-slice for switching current Thread::Light. It only switch when execution context cannot proceed: (select/wait_for_single_fd, waitpid, sleep, Queue/SizedQueue blocking, Thread*#join/#value) along with Thread.pass > Regarding the fact that I regret adding threads to the > language because they are too difficult to use correctly, I > don't want to add yet another variation of threads. So the > current light-weight thread proposal is not acceptable to me. OK. I'm trying to avoid the same mistakes, so I opted to avoid timeslice switching. The current design discourages Mutex/ConditionVariable (holding ANY Mutex acts like 1.8 Thread.exclusive) and only switch at well-defined points. > It seems that there are two types of concurrency demand. The > one for CPU intensive tasks and the other for I/O intensive > tasks. To address the former, @ko1 is working on Guilds. And > he said the concept of Guild can be applicable to I/O > intensive tasks as well. I am not confident about his > statement yet. But I'd like to see if Guild works (or not). Right, I am also skeptical as Guild is implemented using native thread. "I/O intensive" mean different things. Examples: 1. serving large files to clients in fast LAN (10G) 2. serving tens/hundreds of thousands of clients from far off corners of the world with slow, crappy connections They require different approaches; current native Thread is great for 1. (especially if the local HDD/SSD is a bottleneck). Thread::Light should be ideal for 2; but can also handle 1 if combined with native Thread / fork. My goal is to be able to allow the programmer to support both 1. and 2. in the same process. > If Guild turns out to be unsuitable for I/O intensive tasks, there's a chance for the original auto fiber for I/O intensive tasks. > Recently I talked with some companies using Ruby (on Rails) > and found out that the expectation for I/O multiplexing is > greater than I thought. If the demand is big enough, it may be > better to add auto fiber to the language without waiting for > Guilds, because it's simpler and easier to use. We need more > investigation. Really? It seems to me nobody is interested in this feature, so I'll probably abandon it as I can't afford to hack on Ruby much longer. Note: as you know, I won't make public appearance due to privacy and personal safety concerns, I also won't use proprietary messaging systems; so all I know is what I read in email.