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 E4A291F576 for ; Mon, 29 Jan 2018 09:48:42 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 319E3120A5A; Mon, 29 Jan 2018 18:48:41 +0900 (JST) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by neon.ruby-lang.org (Postfix) with ESMTPS id 615FA120A50 for ; Mon, 29 Jan 2018 18:48:37 +0900 (JST) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 4DF251F576; Mon, 29 Jan 2018 09:48:36 +0000 (UTC) Date: Mon, 29 Jan 2018 09:48:36 +0000 From: Eric Wong To: ruby-core@ruby-lang.org Message-ID: <20180129094836.GA30171@starla> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-ML-Name: ruby-core X-Mail-Count: 85217 Subject: [ruby-core:85217] 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" sam.saffron@gmail.com wrote: > I like Task a lot, it is short and makes much sense. I guess there's a risk of namespace conflict with existing code with such a generic name like "Task" or "Job". But, maybe the class name should not matter as much as adding new ones can always cause conflict with existing code. So, based on your add_task proposal; maybe the name of the class wouldn't even matter, and we can use whatever name, (I just chose "async") to create it: foo = Thread.current.async do # some task end foo.class => RubyVM::ThingWeCannotDecideANameFor # (Or Thread.async, because only current is supported atm) foo = Thread.async {} foo.class => RubyVM::ThingWeCannotDecideANameFor In other words, API for usage and class name can be orthogonal. > So conceptually a kernel thread will be allowed to schedule N Tasks. Right. > How would you manage scheduling tasks that are potentially > blocking. Should Ruby opt for a goroutine type implementation > where core just handles spawning "enough" underlying threads > to handle the work, or would the management be at a higher > level and you would spawn N threads and then tasks from said > threads. That would be M:N threading which I am uncertain about. Mainly, I want to still be able to do real blocking operations even when non-blocking operations are supported for sockets: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/85082 https://public-inbox.org/ruby-core/20180124220143.GA5600@80x24.org/ (likewise with recv_io or small IO#sysread on IO.pipe) So "enough" is difficult to determine (not just CPU count). I have use cases which involve multiple mount points which I'd like to be able to optimize for with Ruby. > I think it probably makes sense to always have Tasks coupled > tightly with threads initially cause debugging will be much > simpler. Yes, it's a requirement at the moment since migrating Fibers across Threads is not possible. I think we'd have to give up fast native Fiber switching (ucontext_t) if we want to migrate Fibers across Threads (maybe ko1 can confirm). So that's why "rb_thread_t.afrunq" came to be: > > Changes to existing data structures: > > > > rb_thread_t.afrunq - list of fibers to auto-resume