From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: poffice@blade.nagaokaut.ac.jp Delivered-To: poffice@blade.nagaokaut.ac.jp Received: from kankan.nagaokaut.ac.jp (smtp.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id 1C6A41BA00A1 for ; Wed, 10 May 2017 18:20:35 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id 5BB04B5D8AC for ; Wed, 10 May 2017 19:04:28 +0900 (JST) Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id 2362318CC81A for ; Wed, 10 May 2017 19:04:29 +0900 (JST) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id A2E1D12070F; Wed, 10 May 2017 19:04:28 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by neon.ruby-lang.org (Postfix) with ESMTPS id AA4E91205E0 for ; Wed, 10 May 2017 19:04:24 +0900 (JST) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 4896C1FF34; Wed, 10 May 2017 10:04:23 +0000 (UTC) Date: Wed, 10 May 2017 10:04:23 +0000 From: Eric Wong To: ruby-core@ruby-lang.org Message-ID: <20170510100423.GA23016@starla> References: <20170508063633.GA6821@starla> <4a83bbeb-b22b-61ec-a03f-657746843431@atdot.net> <20170509033806.GA27973@starla> <20170509051223.GA31857@whir> <20170509062353.GB8654@starla> <20170509185140.GA17410@starla> <5c6c1af4-109f-ebd7-07aa-0f8dd77df9b8@atdot.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5c6c1af4-109f-ebd7-07aa-0f8dd77df9b8@atdot.net> X-ML-Name: ruby-core X-Mail-Count: 81089 Subject: [ruby-core:81089] Re: [ruby-cvs:65407] normal:r58236 (trunk): thread.c: comments on M:N threading [ci skip] 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" SASADA Koichi wrote: > Thank you. > > (quote it first) > > Do you have any deadlines or priorities? > > No. I want to make clear your priority to avoid conflicts with me. OK, good to know. > On 2017/05/10 3:51, Eric Wong wrote: > >> (1) lightweight fiber switching by pointer-exchange > >> (w/o copying context). > > > > Out of all tasks here, I am least familiar with this (1). > > This will be learning experience for me. > > > >> (2) auto-fiber swiching > >> (2-1) implement with epoll/kqueue/select > >> (2-2) design APIs to use it > > > > I think I will start on the select implementation first for > > portability, but model our internal API around epoll(*). > > I will probably implement epoll support last, since I am > > most familiar with it. > > > > (*) with current GVL, I expect our kqueue+kevent implementation > > will be faster than epoll in most cases (the API requires > > fewer syscalls). select might be fastest with few FDs. > > (1) and (2) are independent so that we can do it parallel. > > Do you want to try (1) first or can I try (1)? Yes, Doing (1) is good to > learn core internal, but maybe (1) affect many places in VMs. So I want > to try. Anyway we should make new ticket and discuss on it. You should do (1) first, you are the VM expert :) > I guess (2) is not so easy to design APIs. Lets keep changes to C-API internal and experiment, first. First start with modifying rb_wait_for_single_fd() and rb_waitpid() to be auto-Fiber-aware. They will register event watcher and call Fiber.yield instead of releasing GVL to sleep when waiting. Later, we can modify rb_thread_fd_select() and rb_thread_sleep*() and maybe others. > * We need to survey other languages I will study the GHC IO manager, I think they are similar to my vision of using EV_ONESHOT/EPOLLONESHOT with multi-core support: http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf (and also similar to what I used for cmogstored) I do not know the Haskell language, so I will need to study it some. > * We need to define blocking operations: > * blocking operation can switch Fibers automatically (I/O read, ...) > * blocking operation can switch Fibers automatically > (other than epoll/kqueue/select manage-able operations, > extra-C exts providing blocking operations, ...) Basically, I want auto-Fiber to behave like 1.8 green threads, but without timer-based switching. Fiber switch should only happen when operations cannot proceed (I/O, waitpid, sleep, etc), or when user calls Fiber.yield. > And how to provide such difference to users? > * Idea: Documentation > * example: POSIX singal safe functions > * example: Java's thread-safety > Generally, it is hard to use because users should > them carefully (and usually people don't). > * Idea: Provide new APIs which support auto-fibers > (and other blocking operations don't support) > * example: EventMachine, ... (other language example? Python?) > * it is clear for users. > * it is hard to import existing code Exactly, new APIs will take more time to adopt. I don't think it is necessary to introduce new IO APIs. Currently, users expect Thread switch when doing blocking IO (GVL release); it should be easy to understand auto-Fiber switch if IO would block (like 1.8 Thread) Also, there is a NeverBlock RubyGem which made Fibers automatic (like 1.8 threads), but development stopped years ago. Ideally, I want existing code to be able to use net/* in stdlib (and similar) with minimal modification: s/Thread.new/auto-Fiber.new/ > * Idea: Provide a new TracePoint probe > to know blocking operation which does not support auto-fibers. > * This idea is for advanced user to check their scheduling > * I think it is enough because > * advanced user should be production maker. > Automatic tools are preferable. > * not advanced user don't care which operation can stop > forever w/o auto-fiber switching Yes, we can add this once the auto-switch is implemented :) > * We need to define auto-Fiber constructor Perhaps that is a job for matz :) > * ... > > Ah, I remember that we have (2') providing epoll/kqueue like Ruby > interface. (2) use them in scheduler internally and only auto-fibers use > it. However, someone want to use them and want to write their own > scheduler (like nodejs culture). I'm not sure we should expose such > interface but it is valuable to consider. If we decide to provide such > APIs, we need to share the implementation (or shouldn't?). Furthermore, > it is more easy to provide such APIs compare with providing auto-fibers. I don't think exposing new API is necessary, yet. I prefer we focus on internal implementation changes, first, and expose user-visible changes later. > >> (4) Re-implement Queue (some days ago you wrote) > > > > I already had some work-in-progress patches I can cleanup and > > send out to redmine for review later (also ConditionVariable). > > Last I remember, there was a small performance regression for > > small Queue/Condvar waiter lists due to better locality on embed > > structs. However, I think avoiding O(n) rb_ary_delete behavior > > is more important for busy queues. > > OK. Btw, that is [Feature #13552] - it might be ready. > >> (please add your plan if you have others) > > > > I might break out thread.c and io.c into smaller files > > (select/epoll/kqueue/timer_thread/copy_stream/...) > > to make code organization easier. > > Not sure we can do it for io.c. > Please ask someone else. akr / nobu?