From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-2.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_MED,SPF_PASS,T_RP_MATCHES_RCVD shortcircuit=no autolearn=no autolearn_force=no version=3.4.0 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id F0F621F404 for ; Sun, 28 Jan 2018 14:32:31 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 04C82120ADF; Sun, 28 Jan 2018 23:32:29 +0900 (JST) Received: from mail.atdot.net (ik1-326-23156.vs.sakura.ne.jp [153.126.180.160]) by neon.ruby-lang.org (Postfix) with ESMTP id D42A6120ADC for ; Sun, 28 Jan 2018 23:32:25 +0900 (JST) To: Ruby developers , Eric Wong References: <20180123173133.GB14355@starla> From: Koichi Sasada Message-ID: <41283c57-ccfb-9c1b-4126-71da534946c0@atdot.net> Date: Sun, 28 Jan 2018 23:32:24 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180123173133.GB14355@starla> Content-Language: en-US X-ML-Name: ruby-core X-Mail-Count: 85183 Subject: [ruby-core:85183] Re: [Ruby trunk Feature#13618][Assigned] [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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" On 2018/01/24 2:31, Eric Wong wrote: >> * Lock and queue should work with auto-fiber? > I can definitely make Queues work. I think ko1 was mildly > against increasing use of Mutex. > > One safety feature I was thinking about was disabling > auto-switching of Fibers while a Mutex is locked, even. If we name it as Thread-like (Threadlet), we can use all synchronization tools with Threads (I feel it is natural). I'm not sure we should limit to use them on Threadlet or not. 1. Threads and Threadlets can share same synchronization tools -> Good: no learning efforts -> Bad: People can cause sync issues with mis-using or missing syncs 2. Introduce Threadlets special synchronization tools and introduce special rules communicate with other threads -> Good: people can only use good tools (such as Queues) -> Bad: we need to learn new tools and rules If we think `Threadlet` is a special Thread (and the name indicates it), then (1) seems nice for me. With both options, we can enjoy advantages of Threadlet: (a) lightweight creation (b) predictable (than preemptive threads) switching -- // SASADA Koichi at atdot dot net